| === jjohansen is now known as jj-afk | ||
| === ivoks is now known as ivoks-afk | ||
| === amitk-afk is now known as amitk | ||
| * apw yawns | 08:46 | |
| === smb` is now known as smb | ||
| === smb is now known as smb` | ||
| === smb` is now known as smb | ||
| * smb crawls in | 08:48 | |
| === diwic is now known as diwic_lunch | ||
| 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:12 |
|---|---|---|
| apw | depends on X86 && PCI && INPUT && EXPERIMENTAL | 11:14 |
| apw | JamesPage, ^^ | 11:14 |
| JamesPage | Thought that was the case; thankyou! | 11:15 |
| JFo | <sarcasm>I just love never-ending headaches</sarcasm> | 11:16 |
| apw | JFo, they are the pits, a friend of mine has those | 11:29 |
| smb | I hope there is any chance to get rid of them without doing the Chromwell cure. :/ | 11:30 |
| === diwic_lunch is now known as diwic | ||
| apw | ogasawara, fyi added updates to the "mac does not boot amd64 CD" bug on the release page | 12:54 |
| === ivoks-afk is now known as ivoks | ||
| 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:29 |
| 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:30 |
| ogasawara | apw: awesome, thanks | 14:37 |
| tgardner | ogasawara, you're up early. | 14:39 |
| tgardner | ogasawara, do you have a FFE for module-init-tools ? | 14:39 |
| 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:40 | |
| 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:41 |
| ogasawara | tgardner: ack, I'll update the bug with sabdfl's test results and then have robbiew review | 14:42 |
| 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:43 |
| tgardner | ogasawara, ack | 14:44 |
| === ivoks is now known as ivoks-afk | ||
| tgardner | ogasawara, hmm, wth is your launchpad PPA address? I seem to be challenged this morning. | 14:45 |
| ogasawara | tgardner: https://launchpad.net/~leannogasawara/+archive/ppa/ | 14:46 |
| tgardner | nm, leannogasawara | 14:46 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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 | 14:58 |
| robbiew | lol | 15:00 |
| robbiew | tgardner: good man ;) | 15:00 |
| tgardner | robbiew, gotta keep the boss happy. | 15:00 |
| robbiew | heh | 15:01 |
| === bjf[afk] is now known as bjf | ||
| === amitk is now known as amitk-afk | ||
| * ogasawara bails for appt, back in a bit | 17:30 | |
| 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 ... | 17:32 |
| === ivoks-afk is now known as ivoks | ||
| tseliot | smb: do you know what can be causing this? https://pastebin.canonical.com/38003/ | 17:36 |
| 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:37 |
| smb | tseliot, I trie to find what the issue is you might mean | 17:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| smb | tseliot, Or could it be that .o files remain locally after a 64bit buildß | 17:46 |
| tseliot | smb: and how would you deal with that | 17:47 |
| tseliot | ? | 17:47 |
| 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:48 |
| 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:49 |
| apw | tseliot, perhaps you could get us the schroot/dchroot configuration file for the chroot to look at | 17:50 |
| 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:53 |
| tseliot | apw: sure, let me see where that file is | 17:54 |
| tseliot | apw: I don't think I have a configuration file with the "arch" | 17:58 |
| 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 | 17:59 |
| 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:00 |
| 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:01 |
| tseliot | apw: yep | 18:02 |
| smb | So ok, and inside the 32bit chroot you run uname -m and get x86_86, right? | 18:03 |
| tseliot | smb: x86_64 | 18:03 |
| tseliot | so, yes | 18:04 |
| 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:09 |
| 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:10 |
| 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:12 |
| 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:13 |
| smb | lamont, Doing that discussion I am not sure the dchroots are all correct on zinc here | 18:14 |
| lamont | "that discussion"? | 18:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| tseliot | smb: ok, np | 18:21 |
| tseliot | apw, smb: thanks for your help | 18:21 |
| 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:22 |
| tseliot | smb: yes, that's likely. I'm wondering how apps are supposed to find the chroot's arch in pbuilder... | 18:24 |
| 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:25 |
| tseliot | smb: yes and I guess "-a i386" is stored somewhere | 18:26 |
| 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:27 |
| smb | tseliot, So maybe its time to ask people who may understand those tools. ;-P | 18:28 |
| tseliot | smb: that too ;) | 18:28 |
| tgardner | mpoirier, echo "dpkg-buildpackage -B -aarmel" | schroot -c maverick-amd64 | 18:49 |
| * tgardner bails for the day | 19:02 | |
| * smb calls it a weekend | 19:03 | |
| === rsalveti` is now known as rsalveti | ||
| === You're now known as ubuntulog | ||
| * jjohansen has to run for a few min | 19:47 | |
| === jjohansen is now known as jj-afk | ||
| === ivoks is now known as ivoks-afk | ||
| 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:10 |
| 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 | 20:29 |
| === jj-afk is now known as jjohansen | ||
| 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:00 |
| ogasawara | heh | 21:01 |
| ogasawara | bdmurray: http://people.canonical.com/~ogasawara/temp/pkg_stats_xml.patch | 21:03 |
| === ivoks-afk is now known as ivoks | ||
| * ogasawara lunch | 21:26 | |
| 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:51 |
| ogasawara | Sarvatt: cool, thanks for following up. | 22:52 |
| 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:53 | |
| 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 | 22:57 |
| === yofel_ is now known as yofel | ||
| ogasawara | it's bug 615153 in launchpad | 22:57 |
| 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 | 22:58 |
| 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:00 |
| 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:01 |
| lex79 | got it, so Ubuntu will be released with that bug? | 23:02 |
| charlie-tca | I am not qualified to say/know | 23:03 |
| lex79 | I'm asking to all, not just to you, but thanks :) | 23:05 |
| 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:06 |
| mpoirier | ogasawara: mumble ? | 23:25 |
| ogasawara | mpoirier: hi, I think my mumble is acting up at the moment. anything I can help you with here? | 23:32 |
| 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:33 |
| mpoirier | you can write the SRU at the same time you submit the patch. | 23:34 |
| 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:35 |
| 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:36 |
| bjf | mpoirier, you may also want to look at: https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat | 23:38 |
| 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:39 |
| 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:40 |
| 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 ? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!