=== jjohansen is now known as jj-afk
=== ivoks is now known as ivoks-afk
=== amitk-afk is now known as amitk
[08:46]  * apw yawns
=== smb` is now known as smb
=== smb is now known as smb`
=== smb` is now known as smb
[08:48]  * smb crawls in
=== diwic is now known as diwic_lunch
[11:12] <JamesPage> Question: can someone confirm that the ibmasm module is *not* supported on powerpc architecture?  I believe it relies on x86 but wanted to check. Thanks :-)
[11:14] <apw>         depends on X86 && PCI && INPUT && EXPERIMENTAL
[11:14] <apw> JamesPage, ^^
[11:15] <JamesPage> Thought that was the case; thankyou!
[11:16] <JFo> <sarcasm>I just love never-ending headaches</sarcasm>
[11:29] <apw> JFo, they are the pits, a friend of mine has those
[11:30] <smb> I hope there is any chance to get rid of them without doing the Chromwell cure. :/
=== diwic_lunch is now known as diwic
[12:54] <apw> ogasawara, fyi added updates to the "mac does not boot amd64 CD" bug on the release page
=== ivoks-afk is now known as ivoks
[14:29] <smoser> smb, any updates on lucid kernel to -proposed (https://bugs.launchpad.net/ubuntu-on-ec2/+bug/574910)
[14:29] <ubot2> Launchpad bug 574910 in linux-meta (Ubuntu) (and 4 other projects) "High load averages on Lucid while idling (affects: 35) (dups: 3) (heat: 230)" [Undecided,Invalid]
[14:30] <smb> smoser, jj-afk has been fixing up the rebase and bjf[afk] will proceed to prepare the upload as soon as he is not afk anymore
[14:30] <smoser> thanks. 
[14:37] <ogasawara> apw: awesome, thanks
[14:39] <tgardner> ogasawara, you're up early.
[14:39] <tgardner> ogasawara, do you have a FFE for module-init-tools ?
[14:40] <ogasawara> tgardner: so I've got the diff which I was going to ask you to give a quick once over
[14:40]  * smb wonders whether the question is related to the statement...
[14:41] <ogasawara> tgardner: I'm not sure what additional process is involved beyond that in order to upload
[14:41] <tgardner> smb, its tangentially related
[14:41] <tgardner> ogasawara, just robbiew's signoff in the bug. the archive admins'll hold it until then
[14:42] <ogasawara> tgardner: ack, I'll update the bug with sabdfl's test results and then have robbiew review
[14:43] <tgardner> ogasawara, shall I upload the bits from your PPA ?
[14:43] <ogasawara> tgardner: yep that'd work, just munge the version to be proper (ie not have the ~lp630748)
[14:44] <tgardner> ogasawara, ack
=== ivoks is now known as ivoks-afk
[14:45] <tgardner> ogasawara, hmm, wth is your launchpad PPA address? I seem to be challenged this morning.
[14:46] <ogasawara> tgardner: https://launchpad.net/~leannogasawara/+archive/ppa/
[14:46] <tgardner> nm, leannogasawara
[14:48] <tgardner> ogasawara, I think the PPA filter should default to 'Any series'. It always throws me for a loop when I don't immediately see a package that I _know_ should be there.
[14:49] <apw> tgardner, that is a most irritating feature
[14:49] <tgardner> apw, I think thats why I got confused about -meta in teh kernel-ppa last night.
[14:50] <tgardner> now that I think about it
[14:50] <apw> well we were missing some for lucid as well
[14:50] <apw> but +packages is the only page i understand these days
[14:58] <ogasawara> tgardner: have robbiew's Ack for upload in the bug now
[14:58] <tgardner> ogasawara, too late, already uploaded :)
[14:58] <ogasawara> hehe, nice
[15:00] <robbiew> lol
[15:00] <robbiew> tgardner: good man ;)
[15:00] <tgardner> robbiew, gotta keep the boss happy.
[15:01] <robbiew> heh
=== bjf[afk] is now known as bjf
=== amitk is now known as amitk-afk
[17:30]  * ogasawara bails for appt, back in a bit
[17:32] <tgardner> apw, any idea whats the story with readq on ARM ? /home/usr3/ubuntu/ubuntu-natty/drivers/scsi/qla4xxx/ql4_nx.c:716: error: implicit declaration of function 'readq'
[17:32] <apw> tgardner, not heard anything about it ...
=== ivoks-afk is now known as ivoks
[17:36] <tseliot> smb: do you know what can be causing this? https://pastebin.canonical.com/38003/
[17:37] <tseliot> smb: in a 32bit chroot on a 64bit host
[17:37] <tseliot> adding -m32 to CFLAGS and -melf_i386 to LDFLAGS doesn't seem to solve the problem
[17:38] <smb> tseliot, I trie to find what the issue is you might mean
[17:39] <smb> tseliot, and the chroot is started with linux32, so uname -m shows i686?
[17:39] <tseliot> smb: I'm building a kernel module with dkms in a chroot that is not using linux32
[17:39] <tseliot> and the arch is shown as x86_64
[17:40] <smb> that may be the problem
[17:40] <tseliot> smb: do you know of any workarounds apart from using linux-32?
[17:40] <smb> why would you not do that
[17:41] <apw> tseliot, why would you do that?
[17:41] <smb> you want a 32bit build in a chroot
[17:41] <tseliot> right
[17:41] <smb> so you need to start it or have it configured to start with linux32 compat mode
[17:41] <tseliot> it's our build system, I guess
[17:42] <smb> tseliot, I am not really sure I know what you try to do and maybe I do not want to know either
[17:42] <apw> cirtainly you are asking for a world of pain running a 32bit userspace without the compat
[17:42] <smb> I see 2.6.24 mixed with 2.6.36 versions
[17:42] <tseliot> yes, 2.6.24 is the host
[17:42] <apw> so that is to be expected as the real kernel is .24
[17:43] <tseliot> 2.6.32-22 is the guest and 2.6.36 is just part of the path (not an actual kernel)
[17:43] <apw> so the only thing wrong seems to be the missing linux32, but why is that missing?
[17:43] <tseliot> that's a good question
[17:44] <smb> I am actually even surprised that running a 2..6.32 chroot on a 2.6.24 host works... but ok
[17:44] <tseliot> yes, I do it all the time
[17:44] <tseliot> but I don't build kernel modules in a chroot
[17:44] <apw> it probabally has to work else the buildds wouldn't work
[17:45] <tseliot> I'm asked that hoping to get an answer (as I don't work on buildds)
[17:45] <apw> but ... i would concentrate on the linux32 missing, i don't see how that can be right
[17:46] <smb> tseliot, Or could it be that .o files remain locally after a 64bit buildß
[17:47] <tseliot> smb: and how would you deal with that
[17:47] <tseliot> ?
[17:48] <smb> tseliot, The problem is that I do not know how you get to the place you got. Is the directory cleaned, or is it like our builders which start from a clean point
[17:49] <tseliot> smb: I think it starts from /var/lib/dkms/compat-wireless-ath9k-htc/source (which is clean) and copies that to /var/lib/dkms/compat-wireless-ath9k-htc/build and starts the build
[17:50] <apw> tseliot, perhaps you could get us the schroot/dchroot configuration file for the chroot to look at
[17:53] <apw> tseliot, as smb said, the other option is the directory was not clean from a 64 bit build (the build directory) and it could have looked it cause the files its moaning about are .tmp.xxx files which you'd not see by default
[17:54] <tseliot> apw: sure, let me see where that file is
[17:58] <tseliot> apw: I don't think I have a configuration file with the "arch"
[17:59] <smb> tseliot, Is that a machine where you can login and start the chroot yourself?
[17:59] <smb> tseliot, Then what type schroot or dcroot
[18:00] <smb> depending on that its either /etc/schroot/schroot.conf or /etc/schroot/schroot.d/something or /etc/dchroot/dchroot.conf or so
[18:00] <smb> cannot remember the full detals
[18:00] <tseliot> apw, smb: no, I don't have access to that machine, however I can reproduce the problem in my pbuilder chroot
[18:01] <smb> tseliot, You mean you *have* reproduced it or you *may* if we want to?
[18:01] <apw> tseliot, so you have also hit this problem in a pbuilder env ?
[18:01] <tseliot> smb: I have reproduced the problem here in pbuilder and I'm currently inside the chroot
[18:02] <tseliot> apw: yep
[18:03] <smb> So ok, and inside the 32bit chroot you run uname -m and get x86_86, right?
[18:03] <tseliot> smb: x86_64
[18:04] <tseliot> so, yes
[18:09] <apw> tseliot, ok even on my natty kernel i get i686 in  my 32bit chroots
[18:09] <jjohansen> apw: is the overlayfs you mentioned fuse based, or is there another one?
[18:09] <apw> there much be something wrong with the chroot setup
[18:09] <apw> jjohansen, no that is kernel based
[18:09] <apw> (the one i mentioned is)
[18:10] <jjohansen> apw: okay, when I looked all I found was miklos and neils fuse one
[18:10] <apw> jjohansen, look for overlayfs and hybrid union mount in the lkml archives
[18:12] <apw> tseliot, so we need to see the command line and configuration for the chroot you are using
[18:12] <apw> tseliot, as all of ours in all combinations say i686 and yours does not
[18:12] <tseliot> apw: ok, how do I do that? Shall I tell you how I created the chroot?
[18:13] <smb> tseliot, pastebin /etc/dchroot.conf or whatever
[18:13] <apw> tseliot, well the command you typed to get in there you should be able to cut-n-paste
[18:13] <apw> and what smb said :)
[18:14] <smb> lamont, Doing that discussion I am not sure the dchroots are all correct on zinc here
[18:14] <lamont> "that discussion"?
[18:15] <smb> lamont, Trying to find out why tseliot 32bit chroot tells him x86_64 in uname -m
[18:15] <lamont> did he say 'linux32 dchroot'?
[18:15] <smb> lamont, The I looked at zinc for reference and maverick and lucid have linux32 in the config for -i386 but not hardy or karcmic
[18:16] <tseliot> apw, smb: there's no such directory http://pastebin.ubuntu.com/504030/
[18:16] <lamont> smb: fixed
[18:16] <lamont> that is, tseliot: pls try now?
[18:16] <smb> lamont, Now thats, service :) thank
[18:16] <smb> s
[18:17] <tseliot> lamont: what shall I try?
[18:17] <lamont> tseliot: the 32 bit dchroots on zinc should now think they're 32-bit, even when you don't say 'linux32 dchroot'
[18:17] <smb> lamont, The notice of zinc was just coincidence and has nothing to do with what tseliot actually does
[18:17] <lamont> meh
[18:17]  * lamont goes back to sleep
[18:17] <tseliot> apw, smb: I created my chroot with pcreate -a i386 -d lucid mychroot
[18:18] <apw> tseliot, whats in /etc/pbuilder*
[18:18] <kees> tgardner: so, dmesg says this:
[18:18] <kees> [    0.943957] tg3 0000:01:02.0: PCI INT A -> GSI 30 (level, low) -> IRQ 30
[18:18] <kees>   30:  212807004          0          0          0   IO-APIC-fasteoi   eth0
[18:18] <kees> so I guess tg3 is there, but it's not clear to me if that's for tx or rx
[18:19] <tseliot> apw: buildd-config.sh  and pbuilderrc but they're pretty useless as my ~/.pbuilderrc overrides them
[18:19] <kees> tgardner: any clue how to further debug?
[18:19] <tgardner> kees, maybe you could futz noapic, etc
[18:20] <tgardner> kees, yeah, boot with noapic
[18:20] <smb> tseliot, Unfortunately I never use pbuilder, so I am not really sure how tings works out there or where we find things... :/
[18:20] <kees> tgardner: ok, will give it a shot
[18:21] <tseliot> smb: ok, np
[18:21] <tseliot> apw, smb: thanks for your help
[18:22] <smb> tseliot, Generally the problem seems to me that the build may somewhere try to find out which architecture it is running on with uname -m and then getting confused when it is 64bit which the linker in the 32bit environment does not know
[18:24] <tseliot> smb: yes, that's likely. I'm wondering how apps are supposed to find the chroot's arch in pbuilder...
[18:25] <smb> tseliot, Sort of I thought that pbuilder, too should need to use the 32bit personality when starting a 32bit chroot , but I cannot say how you would tell it. Somehow I would expect it to do so when you pass -a i386
[18:26] <tseliot> smb: yes and I guess "-a i386" is stored somewhere
[18:27] <tseliot> I'm using pbuild which is a wrapper for pbuilder
[18:27] <smb> tseliot, May that be something pitti wrote?
[18:27] <tseliot> smb: mterry did
[18:28] <smb> tseliot, So maybe its time to ask people who may understand those tools. ;-P
[18:28] <tseliot> smb:  that too ;)
[18:49] <tgardner> mpoirier, echo "dpkg-buildpackage -B -aarmel" | schroot -c maverick-amd64
[19:02]  * tgardner bails for the day
[19:03]  * smb calls it a weekend
=== rsalveti` is now known as rsalveti
=== You're now known as ubuntulog
[19:47]  * jjohansen has to run for a few min
=== jjohansen is now known as jj-afk
=== ivoks is now known as ivoks-afk
[20:10] <jcastro> I keep reading different things about TRIM support for newer SSDs on the internet, can someone confirm that it just works ootb in 10.10?
[20:29] <lamont> I'm going to kill https://edge.launchpad.net/~kernel-ppa/+archive/pre-proposed/+build/1979124 since it's run out of disk space.  There's a patch it should probably get.
[20:29] <lamont> and might already have - that build has been running for 2 days now
=== jj-afk is now known as jjohansen
[21:00] <ogasawara> bdmurray: I've got a one line patch to the pkg_stats_xml.py file, but can't push to the canonical-qa-tracking repo since I'm not Canonical QA anymore.
[21:00] <ogasawara> bdmurray: if I send it to you, could you apply and push?
[21:00] <bdmurray> ogasawara: I can't believe you are even asking!
[21:01] <ogasawara> heh
[21:03] <ogasawara> bdmurray: http://people.canonical.com/~ogasawara/temp/pkg_stats_xml.patch
=== ivoks-afk is now known as ivoks
[21:26]  * ogasawara lunch
[22:51] <Sarvatt> ogasawara: https://bugzilla.kernel.org/show_bug.cgi?id=16322 is fixed, it turns out it needed an extra commit backported for 2.6.35 to work
[22:51] <ubot2> bugzilla.kernel.org bug 16322 in Other "WARNING: at /arch/x86/include/asm/processor.h:1005 read_measured_perf_ctrs+0x5a/0x70()" [Normal,Resolved: patch_already_available]
[22:52] <ogasawara> Sarvatt: cool, thanks for following up.
[22:53] <ogasawara> Sarvatt: looks like the patches will be propagating through stable so we'll get them automatically when we sync up with upstream stable
[22:53]  * Sarvatt nods
[22:57] <ogasawara> bjf, sconklin: for bugs like the above I'm tagging "2.6.35.y" as we don't yet know the exact upstream stable version the patches will land in
=== yofel_ is now known as yofel
[22:57] <ogasawara> it's bug 615153 in launchpad
[22:58] <ubot2> Launchpad bug 615153 in linux (Ubuntu) (and 1 other project) "WARNING: at /build/buildd/linux-maverick-2.6.35/arch/x86/include/asm/processor.h:1005 read_measured_perf_ctrs+0x6c/0x80() (affects: 33) (dups: 38) (heat: 315)" [Medium,Triaged] https://launchpad.net/bugs/615153
[22:58] <bjf> ogasawara, if it makes you happy, it makes me happy :-)
[22:58] <ogasawara> heh
[23:00] <lex79> hi, I reported this bug 653274
[23:00] <ubot2> Launchpad bug 653274 in linux (Ubuntu) "Plymouth doesn't show Kubuntu logo with Nvidia proprietary driver (affects: 2) (heat: 10)" [Undecided,Confirmed] https://launchpad.net/bugs/653274
[23:00] <lex79>  is it a knew bug ?
[23:01] <charlie-tca> It has been this way for Xubuntu all the since alpha2. It shows the text screen in VBox and with hardware drivers
[23:02] <lex79> got it, so Ubuntu will be released with that bug?
[23:03] <charlie-tca> I am not qualified to say/know
[23:05] <lex79> I'm asking to all, not just to you, but thanks :)
[23:06] <ogasawara> lex79: considering the Maverick kernel was frozen a few weeks ago, if it's not a critical bug fix, it's not likely to be resolved by the 10.10 release.
[23:06] <lex79> ogasawara: ok thanks to plymouth so ;)
[23:25] <mpoirier> ogasawara: mumble ?
[23:32] <ogasawara> mpoirier: hi, I think my mumble is acting up at the moment.  anything I can help you with here?
[23:33] <mpoirier> just following up on your email.
[23:33] <ogasawara> mpoirier: did my feedback make sense?
[23:33] <mpoirier> 1) I thought the SRU process was a two-step process.
[23:33] <mpoirier> I understand it doesn't have to be.
[23:34] <mpoirier> you can write the SRU at the same time you submit the patch.
[23:35] <bjf> mpoirier, normally, you have a bug, you modify the bug to have the SRU justification and then you submit a patch containing a buglink and the SRU justification
[23:35] <ogasawara> mpoirier: yep, what bjf said
[23:36] <mpoirier> Ok got it - the first and only time I did an SRU, the patch had already been submitted.
[23:36] <mpoirier> I'll send again.
[23:38] <bjf> mpoirier, you may also want to look at: https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat
[23:39] <bjf> mpoirier, what this doesn't go into detail about is that the SRU justification is part of the email
[23:39] <bjf> mpoirier, even for a single patch there is usually a cover-letter email, and that contains the SRU Justification
[23:40] <ogasawara> mpoirier: I'd also update the commit message title to be pre-fixed with "UBUNTU: SAUCE:"
[23:40] <ogasawara> mpoirier: that way whomever applies it doesn't have to fix it up
[23:40] <bjf> mpoirier, what ogasawara just said is covered in the above wiki page
[23:59] <mpoirier> bjf: ogasawara: the original author submitted 6 patches and we all want them, meaning they should all be part of the SRU.  Do I have to submit all 6 patches individually or can I prepare a pull request with all 6 patches included ?