=== asac_ is now known as asac [02:36] so when I run kvm -cdrom foo.iso, can I change foo.iso to a different iso without rebooting? [02:43] lamont: yes, you need to use the qemu console for that, use ctrl+alt+2 to access the console ctrl+alt+1 to go back to the VM [02:43] you can then eject and mount a new CD (don't remember the syntax but there is help included IIRC) [02:45] cool [02:46] and if the machine has never been defined in qemu, I can still talk to it (kvm cli instance) with the qemu console? [02:48] yeah, kvm is using qemu so the ctrl+alt+X shortcuts should work (even with the other frontends like VNC) [02:55] coolness [14:44] I am trying to track down a memory leak. the memory does not get freed when I exit the app. someone suggested I look at /proc/meminfo [14:45] is there a tool that will show me those on a graph so I can look for deltas? [14:47] CarlFK: something like slabtop? [14:48] assuming you are looking at a kernel mem leak [14:51] amitk: not what I was hoping for (a graph) but I am open to suggestions - looking at slabtop [14:54] CarlFK: another one to look at might be sysstat [14:54] isag - Interactive System Activity Grapher for sysstat [14:54] that sounds like what I want [15:01] amitk: um... how do I run sysstat? "sysstat is already the newest version; -bash: sysstat: command not found; $ man sysstat; No manual entry for sysstat [15:02] <_ruben> sysstat package has iostat and some other tools [15:02] ah - got it [15:04] mjg59: Does 'Input: atkbd - expand Latitude's force release quirk to other Dells' seem like a candidate for 2.6.27.y ? [15:09] I don't see why not [15:17] rtg: is that related to eject key hang? [15:17] BenC: thats what I'm thinking. [15:17] rtg: definitely sounds like it [15:18] rtg: too bad my latitude doesn't have a cdrom or I would test that theory [15:18] BenC: I don't have the equipment back yet to test with, but shold by weeks end [15:18] It is, yeah [15:18] Since there's a keyboard grab for the eject key and it doesn't get released until the key gets released [15:18] good deal then [15:19] Which it never does [16:41] rtg: there? [16:41] asac: yep [16:41] rtg: do you have an ipw 50XX chipset somewhere? [16:41] apparently the thing that came after 4965 [16:42] asac: Shirley Peak, iwlwifi 5K [16:43] asac: I have 2 of those [16:47] rtg: are those identical? [16:49] asac: Model 512_AN, and Model 533_AN. don't know the differences between them since they are too big to fit any PCIe slots that I have. [16:49] rtg: oh so you cannot test them? [16:51] asac: not easily. [17:04] rtg: so. do you have any chipset at hand that doesnt connect with WPA in intrepid ;)? [17:04] (and that connects properly with wpasupplicant manually) [17:05] asac: do you mean with a simple Open AP? [17:05] no with WPA [17:05] there are a bunch of regressions with iwl ... and other drivers [17:05] asac: oh, you are asking if there are any drivers that _fail_ to connect with WPA, right? [17:05] rtg: and at best such chipsets that still work with wpasupplicant manually [17:06] I use iwl4965 and ath5k every day, connecting to a WPA/PSK/TKIP AP. I never have problems. [17:06] rtg: with NM? [17:07] asac: always. in fact. I've never use wpa_supplicant manually. [17:07] rtg: i think the biggest prob is the IPW 50XX chipset ... i have reports that that doesnt even work with PSK [17:07] but works with supplicant alone [17:07] all others have issues with enterprise network [17:07] stock 2.6.27, or LBM? [17:07] only some users report that its just slow [17:07] rtg: thats all stock i think. [17:08] asac: I'm not surprised that there are issues with the stock kernel. The wireless release was totally flubbed. [17:09] rtg: maybe you have a setup where connecting with NM takes a bit longer than one want? [17:09] asac: 1-2 seconds, about what I'd expect. [17:09] rtg: so how can we ensure better in future [17:09] ? [17:09] is there anyway to better deal with such "flubbed" wireless releases on our side [17:09] ? [17:10] asac: since we aren't upstream developers for wireless, we pretty much get what we're given. [17:12] rtg: who is upstream for iwl? just those intelliwireless folks? [17:12] asac: yep - I think we'll meet some of them at UDS. [17:13] and who maintains the wireless stack in vanilla kernel? [17:13] linville and crew [17:13] i mean most likely someone pulls in stuff from those intelli folks [17:13] ok [17:13] so redhat ;) [17:13] or is that wrong? [17:14] I think John Linville is pretty distro agnostic. [17:14] ok. thought he had a redhat address [17:14] rtg: and atheros is done by atheros in-house and then pushed over the wall? [17:16] All of these wireless drivers are developed in the open using Linville as the maintainer. Subscribe to linux-wireless@vger.kernel.org [17:17] ok thanks [18:29] hey amitk & lamont [18:31] morning [18:32] how goes it lamont? [18:32] lamont: I'm getting complaints that LBM didn't fix the b44 problem. [18:33] rtg: last I looked it wasn't in the archive (as I saw it)... where should I go grab it from [18:33] ? [18:33] checking... [18:34] https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.27/2.6.27-7.5 [18:34] lamont: does it need further stroking? Its marked DONE [18:42] rtg, hi [18:42] rtg: no, it means I need to add intrepid-proposed to my list [18:45] lamont: doh :) [18:46] NCommander: need something? [18:46] rtg, I'm trying to figure out who knows what I need to do to get a ports kernel release (and to get my branch blessed as the next offical tree). I have someone willing to sponsor to upload once the kernel team says its ok [18:47] smb_tp is the guy [18:47] huh? [18:49] NCommander, Ah sure. If you have updates, post a message to the kernel-team mailing list, stating where to get (ideally pull) the changes from [18:50] smb_tp, I have a 2.6.27.4 tree, but its not based off the old tree (git rebase was never meant to go four releases, so I had to start from linus branch and cherry pick) [18:50] NCommander, are you working on a specific architecture? [18:50] smb_tp, all of them, but PowerPC is my priority [18:50] Its been test built on all architectures [18:50] ANd smoke tested on x86 and powerpc. I'm looking for people to smoke test them on sparc, ia64, and hppa (qemu-system-sparc doesn't like my laptop, and I can't find a good ia64 or hppa emulator) [18:51] NCommander, I guess munkfish would have to be involved a bit (since he did a lot up to now) [18:52] smb_tp, he already has been involved :-) [18:53] NCommander, Cool :) ia64 is a bit of a trouble. I only got access to a porter machine, so I can compile but not run a kernel [18:53] smb_tp, yeah, same problem here [18:53] smb_tp, but I did get permission to run daily runs on my ia64 porting box [18:53] rtg, Did you have such a beast or was that BenC [18:53] (my contact at HP is trying to get the same for HPPA) [18:53] I'm handling powerpc dailies, and I'm using spooky for sparc [18:54] I just need to throw dak or repopro somewhere [18:54] BenC has the ia64 [18:54] THe installer is hosed on ia64 (a lot of things that should be built as modules are compiled a y, but I don't know enough about the architecture to know what should and shouldn't even be built) [18:55] NCommander, sounds great. So maybe you just have to announce what you want on kernel-team mailing list and if there are no objections just let me know where your tree can be pulled from [18:56] smb_tp, its on zinc already: mcasadevall\ubuntu-jaunty-ports :-) [18:56] NCommander, Yep same with me. I got it somewhat to compile but saw there were several module issues like that [18:56] NCommander, Great. :) So there were is done [18:56] Someone with an ia64 is going to have to bash the kernel with a hammer. I found ski, but it needs a special kernel configuration to be usable, so I might add a flavor [19:01] NCommander, yeah, most likely. But otherwise you seem to have covered the ground well. The only thing left is some sort of announcement (if you didn't already and I missed that). Not that someone feels stepped onto... [19:02] smb_tp, I also ported AppArmour to the port architectures ;-) [19:02] * NCommander was extremely busy [19:02] It compiled without issue, its just testing it since there is no documentation that I could find :-/ [19:04] NCommander, If it boots, its not too bad ;-) [19:04] * NCommander is working hard to make the port architecture be awesome again [19:05] NCommander, Thanks a lot for that [19:06] Only doing what I do best :-) [19:06] * NCommander is a debian porter [19:06] A part of me wants to port Ubuntu to the m68k ... [19:07] :) [19:07] Although mips is much more realistic [19:07] A part of sebner only wants to support x86 and x86_64 :P [19:07] Mostly because I know someone with suitable buildd hardware, and I have an interest in architecture [21:02] infinity, ping [21:02] NCommander: Yeah? [21:03] infinity, I need you to weigh in on a question about PPAs, and giving one to the ports kernel team that is non-virtualized. Cprov told me to ask the distro team for permission who passed me to the buildd admins :-) [21:04] (building the ports kernel on x86 is sorta an exercise in futility) [21:05] NCommander: Ugh. As much as I love ports (and would like the see the ports kernels stop sucking), there are some policy and security reasons for not allowing community PPAs to touch the non-virtual buildds. [21:05] * NCommander whacks head on the desk [21:05] I was told an exception could be granted if I got an ack by the proper teams [21:05] But I seem to be going around in a circle [21:06] infinity, second BTW, I have a question about the powerpc builders (I'm told they have issues with Hardy, and I was hoping I could get more information so we could track down equivelent hardware and debug) [21:07] NCommander: If you can get your hands on some old Xserves, it becomes pretty self-evident under load. [21:07] NCommander: Repeated OOPSing until you get a hard lock. [21:07] infinity, oh, its an issue under load? [21:07] Damn it, thats anonying [21:08] THe kernel post hardy hasn't been touched until about two weeks ago [21:08] NCommander: I tihnk we have some dumps somewhere of the OOPSes. I'm a bit swamped right now to go hunting, though. :) [21:08] IF you could get me the specific model of Xserve [21:08] I can try and track one down before the next LTS [21:08] (or issue a SRU for hardy to fix it if I can track it down) [21:08] NCommander: Yeah, I can dig up some info. I just can't do so right this instant. [21:08] SUre, no rush, we still have two years to fix it ;-) [21:10] Well, I'd *love* to see it fixed in an SRU. [21:10] Having the PPC buildds on an ancient release is not my idea of good times. [21:10] No kidding [21:10] OUr glibc build has about five hacks to disable parts of the test suite [21:11] ITs no just PPC team member has an xserve [21:11] I know. [21:11] Yeah, I don't either. [21:11] (a few IBM servers, and a small army of G4/G5s :-)) [21:11] My main PPC devel machines are a 32-bit G3, and an IBM PowerStation. [21:11] You will be happy to know jaunty will be sporting a 2.6.27.4 kernel [21:11] (and I'm seeing if I can get the TB to approve a backport of the kernel as linux-ports-backport to intrepid so we have parity on that distribution) [21:12] Which also reminds me, I need to make our yaboot love my Powerstation. [21:12] ugh [21:12] I don't even want to think the last time yaboot was touched [21:12] Unless someone feels like finding YDL's patches and doing so for me. *hint* [21:12] * NCommander adds it to the TODO for today [21:12] infinity, if you care to sponsor, and help ACK making my kernel branch the offical jaunty ports one ;-) [21:13] Given that it came with YDL installed, I know they have patches. They weren't kind enough to send me a source CD, though, and I've not had a chance to go hunting. [21:13] I don't have the same hardware, but I'll post a source package to my PPA (at least THAT works), and then point you to it to test [21:14] But, yeah. Regarding non-virtual PPAs... We'll need to discuss precisely who and how many people would be able to upload to it, and then perhaps see if we'd need any formal paperwork, or if we're happy with our trust level with those people, etc. [21:14] infinity, personally, I would just want it to be snapshots of our git tree [21:15] No direct uploads would be necessary [21:15] The general problem with PPAs is that they're much lower exposure than the archive itself, so it leaves much longer windows of opportunity for people doing Very Bad Things to those machines through PPA uploads. [21:15] Right [21:15] I have managed to get approval to run sbuld and friends on four of the five port architectures [21:15] so if I can't get a non-virtual PPA [21:15] I'll cobble something together [21:15] Which are you missing? [21:16] HPPA [21:16] I can do that. [21:16] Cool [21:16] HP provided the itantic [21:16] I have a (slow) PPC [21:16] I have some very fast PPC hardware too. [21:16] And sistpoty already blessed using spooky (aka REVU) as the sparc builder [21:16] I need people to smoke test kernels [21:16] I don't have physical access to any of these machines [21:17] and someone has to beat the ia64 installer w/ a hammer of pain [21:17] So, yeah. If we don't want to be bothered too much with the possibility of red tape involved in abusing LP for this, I can certainly help with daily builds. [21:17] infinity, I need a place to setup dak and wanna-build ... (I've done it before; back when I was an archive manager briefly for the m68k port ;-)) [21:18] You worked in Debian 68k? [21:18] Must have been after I stepped down. [21:18] and ARM [21:18] And MIPS [21:18] I ran four buildds [21:18] and our w-b after we got kicked off buildd.d.o before moving to d-ports.org [21:18] Yeah, that's way after my time. [21:19] I kinda gave up around the time we became a non-release arch. [21:19] Lost motivation. [21:19] Actually, we got a new glibc now [21:19] FreeScale did the enginneering work [21:19] Which means its likely we will return in squeeze [21:19] NPTL? [21:19] NPTL [21:19] :-) [21:20] Nice. I wonder how much of my groundwork got included in that. [21:20] * infinity shrugs. [21:20] One of the cool things about coldfire and m68k being nearly the same architecture [21:20] * NCommander also did work bootstrapping coldfire debian [21:20] Sadly, I got the board with a hardware fault on it [21:20] They are the same, module a few instructions. [21:20] No one ever claims that i386 and i686 aren't the same arch, so why split hairs? :) [21:20] infinity, well, that's why we have lpia [21:20] For better or worse [21:20] My ColdFire board is very dusty these days. [21:20] infinity, I got my from Stephan [21:21] infinity, I actually got as far as a native GCC bootstrap, and booting from flash directly [21:27] infinity, actually, I think our yaboot problem is simply we're a year behind on the last current release [21:28] NCommander: That's possible. Given that YDL's Powerstation release is actually a completely seperate CD from their "normal" PPC release, though, I'm assuming there's either a custom yaboot, custom kernel, or (likely) both on there. [21:28] There are issues with the kernel when you compile in support for multiple platforms [21:28] It crashed and burned when I tried to add anything beyond CHRP and NewWorld [21:29] They can get more than one kernel on a CD, mind you. [21:29] But, yeah, that might be beyond YDL. [21:29] They have some great technical people, but when it comes to user-friendly, they fail. [21:29] infinity, what happens when you try and boot on the powerstation? [21:30] I almost audibly cried when I saw their default desktop. It's... It's why most people think UNIX is terrible. [21:30] Its based off Red Hat [21:30] What do you expert? [21:30] And, to be honest, I don't recall what exactly happens. Dies in yaboot land, though. [21:30] * NCommander is trying to find their SRPMs [21:30] No, RedHat's default desktop is a pretty clean and friendly place. [21:30] Not in the 6.x days which YDL was based off of [21:31] YDL's reminds me of CDE, circa 1993. [21:31] infinity, what version of yellow dog are we talking about? [21:31] Booted, and was like, "Oh hai, IRIX, I've missed you!" [21:32] IRIX was my first UNIX ever ;.; [21:32] NCommander: The "latest", I imagine... Whatever shipped with my Powerstation. Let me find the DVD. [21:32] DVD claims it's "Version 6". [21:32] Ok [21:32] "Powerstation Edition" [21:32] so there are no yaboot differences between powerstation and regular [21:32] X11 and the kernel is where the changes are [21:34] infinity, ok, YDL ships with yaboot 1.3.13 with specific changes [21:34] so its a just matter of diffing [21:36] o_o; wow, lot of patches [21:36] and no patch system in the deban packaging [21:36] nice [21:37] NCommander: Yeah I know, kinda annoying. [21:37] nothing powerstation specific here [21:38] Wait [21:39] who makes powerstations? [21:39] IBM does, but they're unbranded. [21:39] http://www.terrasoftsolutions.com/products/powerstation/ [21:39] There are a whole bunch of amiga, and pegasos patches [21:39] Every part inside is IBM, but the box just says "YDL Powerstation". [21:39] and one ppc64 intrd patch [21:40] Anyhow, I have lots of work to do, sadly. [21:40] infinity, I'll ping you if/when I h ot test [21:40] I'd love to take a weekend and figure out the most minimal way to make Hardy support this machine, though. [21:40] infinity, if you however figure out what the error is, it can isolate which patches I need to merge [21:40] NCommander: Ping me on Friday? [21:41] * NCommander shall do so [21:41] That will be after the jaunty kernel lands I hope [21:41] NCommander: I'm taking Fridays off work for a while, so I might have some "community fiddling time". [21:41] very awesome [21:41] speaking of community fiddling [21:41] TheMuso, feel like uploading something? [21:41] NCommander: Sure. What may that be? [21:41] a kernel [21:41] *hears a gunshot* [21:41] um... Shouldn't the kernel team bless that? [21:42] The kernel team has almost entirely washed their hands of ports. [21:42] ^- infinity [21:42] I'm not willing to touch it unless the kernel team really don't want to worry about uploading ports kernels. [21:43] TheMuso: You have my blessing to sponsor any ports kernel uploads. Assuming you have the know-how to do the usual sponsorship vetting/review. [21:43] TheMuso: The primary kernel team has almost no interest in them, hence the split. :/ [21:44] I'm just glad the split happened after Hardy, so the hardy kernels are at least somewhat homogenous. [21:44] infinity, the only reason they support lpia is because its not that hard to keep it building [21:44] Intrepid ports kernels are a mess. :/ [21:44] infinity, yeah, it took most of the cycle to clean that up. We only got it fully working towards final freeze (and the installer is still an absolute trainwreck) [21:44] infinity: Yeah the sponsoring is no problem. NCommander Alright, what git tree am I working with, your ports tree? [21:45] TheMuso, that would be mine, but the changelog isn't up to date (you need to call the proper rules to make the changelog be generated correctly) [21:45] NCommander: Are there plans to keep ports kernels based on the non-ports git from here on it? [21:45] s/it/in/ [21:45] NCommander: I understand that. [21:45] infinity, unless a port because offically supported again, yeah [21:45] NCommander: Having different kernel versions, slightly different patchset, etc, between ports is... Terribad. [21:45] infinity, not for jaunty [21:46] infinity, we're actually half a revision higher than the mainline :-) [21:46] (mainline is .2 with cherry picking, ports is .4) [21:46] That still feels icky, to a man who has many different arches at home. [21:46] Same here [21:46] Agreed. [21:46] How abotu I add amd64 and i386-generic support to ports [21:46] I like all my systems to be predictably similar. [21:46] Then you can run the same kernel across the board ;-) [21:47] * NCommander actually did his inital cherry picking patch work on amd64, and then removed those files before committing [21:47] * NCommander makes sure the ports tree is up to do [21:47] *date [21:47] TheMuso, you do know how to do a kernel release, right? [21:48] NCommander: Yeah there are docs on the wiki. I'll take care of it once I've processed my morning email and taken care of some other things, but it is on my TODO for today. [21:49] Ok, I'll generate all the ABI files in the meantime, and then add them to the tree once 1.1 is uploaded so we have a constant ABI to base against [21:49] Right. [21:49] TheMuso, since I have done some work in linux-ports-lrm ;-) [21:49] NCommander: Ok cool. [21:49] (its just madwifi, but I figure its worth having) [21:49] linux-rt will need an upload, but thats multiverse, and I need to clear it by its maintainer anyway [22:00] NCommander: I see you posted to the kernel list re this kernel. Are you still waiting for a response to that before we go ahead? [22:00] Thats more moving my tree to ubuntu-jaunty-ports.git [22:00] NCommander: Right. [22:00] I personally want the kernel to hit jaunty so people can test the damn thing [22:00] (its only been smoke tested on powerpc) [22:01] also, not having a kernel package available has blocked work on linux-rt on powerpc, and linux-ports-lrm (its hardware to work against packages that only exist on 127.0.0.1 ;-)) [22:01] s/hardware/harder [22:02] Right. [22:03] We probably should look at linux-ports-lbm as well, but I first rather just make sure the kernel is usable (since I can probably find a PS3 or two user willing to test jaunty) [22:04] also, once this kernel is uploaded, the next ports daily image will tell us if the installer is completely broken [22:04] TheMuso, second BTW< please leave my name on the changelog so if a build FTBFS, I can get direct notification of it [22:04] Well the installer still needs to have some udebs added. Once Colin has merged d-i, I'll add them. [22:05] TheMuso, I added them to the d-i files in the kernel [22:05] NCommander: Ok. [22:05] NCommander: But work needs doing on the d-i side as well. [22:05] ok, well, at least this is progress ;-) [22:05] brb, dinner [23:53] NCommander: hrm when attempting to isnert the change in the changelog using your ports tree, I get the following error. Looks like there may be a tag missing or some such: [23:53] fatal: ambiguous argument 'Ubuntu-2.6.27-0.0..HEAD': unknown revision or path not in the working tree. [23:53] Use '--' to separate paths from revisions [23:53] NCommander: I think you missed something. [23:53] o_o; [23:54] Its possible the repo needs to be tagged 1.1 [23:54] * NCommander hasn't done this before [23:54] Right, and I think the tag is used to display changes between the last upload and head. [23:54] So what do I need to do to fix the tree? [23:55] NCommander: I am not entirely sure. [23:55] Let me see if I can tag and get it to work here [23:55] What was the command you used? === CarlFK1 is now known as CarlF1 [23:57] NCommander: ./debian/rules insertchanges [23:57] Worked fine here [23:58] hrm. [23:58] I'm going to tag it ubuntu-ports-2.6.27-1.1 (we can't overlap with the main kernel, or it will break remotes) [23:58] TheMuso, I'll just tag and commit with the changelog generated and all that [23:58] Well my copy of your tree has no tags. [23:58] My tree has no tags [23:58] NCommander: hrm ok. [23:59] wel [23:59] I do have tags from remotes [23:59] Very strange [23:59] I think its because I restarted the branch things broke [23:59] If it does this again next upload, we'll investiage futher [23:59] NCommander: have a look at this page for instructinos: https://wiki.ubuntu.com/KernelMaintenance