[00:49] <firewave> Hey folk !
[00:50] <firewave> Some people here may tell me how to set the version name of the kernel when compiling it from apt source ? Like '0ubuntu2' ?
[00:54] <firewave> I'm starting a PPA but all my custom kernels had no version string (sad)
[08:16]  * smb crawls in
[08:22] <jk-> hey smb
[08:22] <jk-> any decision on the 3.0.0.0.0.0 ?
[08:22] <smb> jk-, yep we use 10 0
[08:22] <smb> no 11 
[08:22] <jk-> awesome
[08:22] <smb> or maybe 12
[08:23] <apw> jk-, yeah we're getting there, 3.0 breaks a module-init-tools
[08:23] <smb> maybe we encode 11.10 in binary :-P
[08:24] <jk-> apw: yeah, I heard fedora have recently patched it.
[08:24] <apw> yeah we have the fix, but we're not keen to update it this close to A1
[08:25] <ohsix> a1 for oneiric?
[08:25] <apw> ohsix, yes
[08:25] <ohsix> interesting
[09:20] <jussi> Good Morning Kernel Superstars!
[09:20] <jussi> Is there any other information you would like from me regarding bug 791064?
[09:20] <ubot2> Launchpad bug 791064 in linux "Total lockup (Hard reset rquired)" [Undecided,New] https://launchpad.net/bugs/791064
[09:29] <abogani> jussi: Could you try to 1) remove quiet and splash kernel command line options, 2) login remotely on that machine through ssh immediately after boot 3) login in without 3D effects, please?
[09:31] <jussi> abogani: could you give me a little further instruction? How do I do 1. what information do you want from the ssh login? What information do you want after I login without 3d effects?
[09:32] <jussi> abogani: please understand, this just happened, when I reboot, things are ok)
[09:32] <apw> jussi, i think he is assuming it is reproducible
[09:32] <jussi> apw: ahh, it comes occaisionally, but isnt reproduceaable on demand.
[09:32] <apw> jussi, it would be helpful if you could describe what you could see when it hangs
[09:33] <apw> is the screen blank, still has data on it, does the mouse move, does your wireless/lan light still flash
[09:33] <jussi> apw: ok, Ill do it hwere and add it to the bug if useeful.
[09:33] <apw> does the machine respond to the network via ssh etc etc
[09:33] <apw> as 'hangs' is not very meaningful when reading
[09:33] <jussi> The screen goes blank, with the exception of the mouse pointer (non moveable)
[09:34] <jussi> I did not try get in with ssh at this time.
[09:34] <jussi> Using REISUB the machine did not respond
[09:34] <jussi> Hence I thought it may be a kernel issue
[09:35] <apw> jussi, yes probabally is, very hard to know what it is from the original report, with the black screen and visible cursor thats more helpful and might indicate a graphics issue
[09:36] <abogani> REISUB?
[09:37] <apw> sysrq-X letters
[09:38] <jk-> heh
[09:48] <jussi> apw: ahh, thanks for updating the bug, was just getting to it. 
[10:30]  * ppisati be back in a bit...
[11:24] <ppisati> ok, sent
[11:44] <apw> sconklin, what the heck happend to the lucid master branch, it got rebased?  we have lost a version completely according to the changelog, is this what we intended ?
[11:51] <ppisati> sh*t
[11:52] <ppisati> i forgot i rewrote the latest UBUNTU commit in fsl-imx51
[11:52] <ppisati> because i couldn't make fdr printchanges work
[11:57] <apw> heh
[11:57] <apw> i don't think its worth worrying about
[11:57] <ppisati> but it's no more a pull, it's a reset req
[11:57] <ppisati> wait
[11:59] <apw> ppisati, thats not really anything to stress anyone
[11:59] <apw> the Ubuntu- needs fixing for the tooling to work anyhow
[12:01] <ppisati> apw: too late, sent
[12:12] <Kano> hi, in the 3rc1 dir is a headers deb too much and 32 bit is missing
[12:12] <apw> Kano, doesn't supprise me, the switch to 3.0 has cause utter kaos
[12:13] <Kano> daily only has got the 32 bit deb missing
[12:14] <apw> Kano, ok i got rid of the original failed header
[12:14] <Kano> fine
[12:21] <Kano> i think the same module fails with 3 as it did with .39
[12:21] <Kano> maybe use the same patch?
[12:24] <apw> any add-hoc patches would apply if the files were unchanged
[12:30] <apw> ppisati, ok applied
[12:30] <ppisati> apw: cool
[12:31] <ppisati> apw: lunch now, later i'll push the ti-omap4 equivalent
[12:31] <apw> ppisati, works for me
[14:07]  * apw steps out
[14:07]  * smb needs to re-login
[14:47]  * ogasawara back in 20
[14:51] <smb> apw, I had been pulling in cve-tracker changes from security (D-DoD) and resolved the few conflicts. Its pushed out again
[14:54] <cr3> is there a way to identify the form factor of a system programmatically? dmi may provide this information in the chassis section, but this is defined by the hardware vendor so might contain anything like "Netbook PC" or just "Computer" for example
[15:02] <sconklin> apw: I rebased the lucid tree. We had pushed the next release, which FTBFS because the kernel is proposed (which was not supposed to be published) had been published. This forced an additional ABI bump, and in order to make it properly bisectable with the coorect ABI bump, it needed to be redone. All the tags are still there, except the kernel which never built
[15:05] <apw> sconklin, well i seem to have a tag for the missing one, which is how i noticed
[15:05] <sconklin> It's possibly local. In any case that extra tag shouldn't matter, as we'll never deliver that version
[15:06] <sconklin> I'm not sure how you make sure a local tag is deleted when fetching from a repo in which one has been
[15:06] <apw> sconklin, not sure you can, deleting tags is not really someone one does i guess
[15:06] <sconklin> apw: I knew it was not a perfect solution when I did it
[15:07] <apw> cirtainly caused a heap of confusion here when the cve tracker updater moved all the cves forward a revision
[15:08] <sconklin> well, at least I also thought to change the tracking bug for it. Next time I do something like this, I'll email the list
[15:09] <apw> sconklin, so you have deleted the tag for this aborted release ?
[15:09] <apw> even though it was uploaded?
[15:11] <sconklin> yes, as it failed to build on the PPA, and has been deleted, and was never copied to -proposed
[15:12] <sconklin> although it wouldn't bother me to have the tag repushed if you have it, I have no strong feelings either way
[15:13] <apw> sconklin, i guess if the LP librarian doesn't know the version thats ok
[15:14] <sconklin> I can only foresee a problem if someone tries to push it again, and it should fail, and I don't care why . . .
[15:15] <sconklin> it's already been replaced by a higher version
[15:15] <sconklin> in the PPA
[15:16] <apw> sconklin, ok ... gone in mine too
[16:17] <Kano> mjg59: did you look at the reboot code?
[16:36] <mjg59> Kano: No, I ignored it totally
[16:50] <jonpry> mjg59, did you ever find anything in those logs from my lenovo y560p? I would like to work on this bug. If you have any ideas on what the problem actually is, that would be helpful
[16:50] <mjg59> jonpry: Haven't had a proper chance to look. I have some suspicions.
[16:51] <jonpry> hmm
[16:51] <jonpry> I'm sure your guesses are better than mine. Care to elaborate?
[17:36]  * ppisati -> gym
[18:22] <lamont> 2.6.32-32-generic-pae seems to have horribly regressed wrt actually passing traffic around as a NATting firewall.  this is sadness to me
[18:24] <bjf> sconklin, ^
[18:25] <lamont> I trusted you guys so much, and the telco so little, that I spent about 3 hours fighting with it before downreving the kernel and having happiness
[18:25] <sconklin> lamont: I have a vague memory of smb or jjohansen mentioning something related to this
[18:26] <sconklin> lamont: are you running it in xen?
[18:26] <sconklin> ;-)
[18:26] <smb> That would cause it not to boot
[18:27] <sconklin> smb, sorry it was a bit of a joke.
[18:27] <smb> lamont s trouble sounds a bit more networking related... Oh. Doh! :)
[18:27] <lamont> sconklin: nope.  on hardware, as the firewall between me and the internet
[18:27] <jjohansen> sconklin, lamont: I don't remember any regression for network natting
[18:27] <lamont> interestingly, it mostly just works
[18:28] <lamont> wget from a machine on the internal side, routing out PPPoE to the DSL world hangs at random intervals
[18:28] <jjohansen> lamont: how many iptable rules?
[18:28] <smb> sconklin, On the topic of lucid and xen: I am about to push the rebased ec2 branch and upload it to c-k-t ppa
[18:28] <jjohansen> lamont: scratch that, at random intervals sounds like an interrupt regression
[18:28] <sconklin> smb: ok.
[18:29] <sconklin> lamont: have you tried non-pae?
[18:29] <bjf> smb, did you add a tracking bug?
[18:29] <lamont> for t in filter nat mangle; do echo $t $(iptables -t $t -nvL | wc -l); done
[18:29] <lamont> filter 242
[18:29] <lamont> nat 58
[18:29] <lamont> mangle 79
[18:30] <lamont> sconklin: I have not.  and my fellow  users tell me I can play outside of the 9-9 window (-0600)
[18:30] <smb> bjf, Bah, no
[18:31] <lamont> watching tcpdump on port 80, I was seeing the 3-way, then traffic to the site, traffic back (with the ack of the sent data), ack going back to the site, and nothing else
[18:31] <smb> bjf, Then I probably should not upload it but let someone understanding the whole tracking bug stuff mange that tree I pushed...
[18:31] <sconklin> lamont: ok, Thanks for letting me know. Please open a bug and keep me posted. We have the next kernel in flight, and would like to keep up
[18:31] <lamont> I'm guessing that 6GB of ram on an i386 machine wants to have pae, yes?
[18:31] <lamont> sconklin: sure
[18:32] <bjf> smb, if you've done a test of it and are happy, i'm sure sconklin or herton wouldn't mind doting the Is and crossing the Ts
[18:32] <lamont> I'll file a bug with what info I have after lunch.  next shot at it will be sometime tomorrow at the earliest - tonight is busy for me.
[18:32] <sconklin> lamont: yes. I HOPE that the behavior for non-pae is to ignore all above 4G, but I don't know
[18:32] <lamont> ISTR that being what it did
[18:33] <sconklin> smb, bjf: yes, I'd be happy to
[18:33]  * lamont -> lunch
[18:34] <smb> bjf, Yeah, it booted at least on my test system. Which makes me happy enough right now. There is fiddling around with certain amd cpu features which I am not sure of being needed or not within xen. It did not seem to cause issues here so I let it in
[18:34] <smb> but it might need a close track of any feedback from cert/qa testing
[18:34] <bjf> smb, cool! i think that's ready to hand back to the stable team
[18:35] <smb> works for me... :)
[18:35]  * smb thinks its time to open that bottle of cider to celebrate DoD
[18:36] <jjohansen> sconklin: yep the non-pae kernel should just ignore the extra mem
[18:36] <sconklin> jjohansen: thanks. I thought I remembered that right
[18:37] <ohsix> do the hugepages stuff still need pae?
[18:53] <jjohansen> ohsix: no, but it is needed for nx
[18:55] <ohsix> i see
[18:56] <ohsix> alsi i might have missed an important part of that conversation :] i just saw ignore all above 4g but i think hugepages still let you use them, up to the bus limits if available
[19:07] <jjohansen> ohsix: right, pae is needed to do the address magic to switch around the segments of memory to get you past 4G, the 2M and 4M page entry bits are handled by the page tables directly
[19:15]  * jjohansen runs an errand back in 15
[19:18] <hallyn_afk> smb: bug 720095, don't suppose you're willing to reconsider?
[19:18] <ubot2> Launchpad bug 720095 in linux "vsftpd causes a vmalloc space leak in Lucid" [Medium,Fix released] https://launchpad.net/bugs/720095
[19:18] <hallyn_afk> zul: ^ 
[19:19] <smb> hallyn_afk, I saw you guys bitching in the bug. But can you be sure vsftp was the *only* user of that net_ns ?
[19:19] <hallyn_afk> smb: it certainly isn't the only user, we're another :)
[19:19]  * smb certainly will not decide on that on his own
[19:20] <smb> After all it was an experimental feature and *I* am not using lxc. :-P
[19:21] <hallyn_afk> we all know what 'experimental' tag in Kconfigs is good for
[19:21] <hallyn_afk> pretty sure we discussed nixing it altogether at 2008 ksummit
[19:22] <hallyn_afk> anyway i've got no say, but I don't see how we can tell users that no LTS release can use containers until 12/04
[19:24] <smb> hallyn_afk, I know both ways it is evil. And I would say it is nothing we should go one or the other way based on an irc discussion
[19:24] <smb> So I would propose to bring that up on our mailing list
[19:24] <hallyn_afk> which m-l?
[19:24] <smb> kernel-team ml
[19:25] <hallyn_afk> can we cc: ubuntu-server there too?
[19:25] <smb> Should be possible and probably a good idea
[19:25] <hallyn_afk> Did you want me to initiate it?
[19:26]  * smb had hoped for that
[19:26] <hallyn_afk> ok, do i need to be approved to join the m-l?
[19:26] <hallyn_afk> (trying now, in any case)
[19:27] <smb> dont think so. but even if not worst thing is that you end up with the same fate I had for a while (posting stays in mod queue a bit) until I subcribed the servre list
[19:27] <hallyn_afk> smb: oh, but is cross-posting to kernel-team and a public list against a rule (to prevent accidental disclosures), that you know of?
[19:27] <hallyn_afk> all right
[19:28]  * smb hopes hallyn_afk understands its a time of day where he start caring less 
[19:28] <smb> no rule I know of
[19:28] <smb> kernel-team list is public too
[19:29] <hallyn_afk> oh!  heh, i had assumed not :)  cool.  will post today, otherwise someone else will tomorrow :)  thanks
[19:32] <sconklin> As soon as it's midnight UTC Dapper is dead to me
[19:38] <jjohansen> sconklin: I am surprised you are waiting that long, I would have thought you would like to use UTC+11 for Dapper
[19:38] <jjohansen> :)
[19:39] <sconklin> jjohansen: in all honesty, we prepped the last Dapper kernel a few weeks ago, and I started partying then
[19:39] <jjohansen> sconklin: heh, yeah I was aware of what you hoped would be the last Dapper kernel, now you get to make it official :)
[19:56] <apw> sconklin, wasn't it already UTC midnight on the 1st ?
[20:13] <lamont> sconklin: bug 791512 filed
[20:13] <ubot2> Launchpad bug 791512 in linux "tcp connections hang in forwarding machine" [Undecided,New] https://launchpad.net/bugs/791512
[20:14] <sconklin> lamont: thanks!
[21:02]  * jjohansen -> lunch
[21:45] <skaet> sconklin, bjf - Dapper officially EOL.   Announce is out. 
[21:46] <sconklin> skaet: woohoo!
[21:46] <skaet> :)