| rsalveti | bjf: cool, thanks | 00:38 |
|---|---|---|
| === jjohansen1 is now known as jj-afk | ||
| === bjf is now known as bjf[afk] | ||
| === amitk-afk is now known as amitk | ||
| === amitk is now known as amit-afk | ||
| === amit-afk is now known as amitk | ||
| === smb` is now known as smb | ||
| * apw yawns | 08:23 | |
| * smb looks whether apw looks a bit sweaty | 08:23 | |
| apw | huh ? | 08:23 |
| smb | How does it feel being dragged into mumble hell | 08:24 |
| === artnay_ is now known as artnay | ||
| tseliot | smb, apw: do you know where's the script that's called by "debian/rules insertchanges"? I'm asking as it's not working correctly for me (I'm using a customised flavour) | 08:36 |
| apw | tseliot, in part some of it is in the rules (the bit which works out the start point) and the second debian/scripts/misc/git-*log* | 08:37 |
| apw | but i suspect its the rules themseleves which fail | 08:37 |
| apw | the key think is they look for the Ubuntu-<version> messages in the commits to find them | 08:38 |
| apw | s/them/the start commit/ | 08:38 |
| apw | tseliot, ^^ | 08:38 |
| tseliot | apw: ok, thanks | 08:39 |
| smb | My workaround for that is sometimes "git log <whatever range>|./devian/scripts/misc/git-ubuntu.log > bla" and then include the output in the changelog with my favorite editor | 08:39 |
| apw | tseliot, you can find the version number it is looking for using the fdr printenv | 08:39 |
| tseliot | apw: this looks correct (at least to my sleep deprived eyes) http://pastebin.ubuntu.com/533394/ | 08:42 |
| apw | tseliot, so this is the first version on the branch as it is looking for 2.6.37-0.0 | 08:43 |
| apw | prev_revision = 0.0 | 08:43 |
| tseliot | apw: yes, that's correct | 08:43 |
| apw | so unless you have an UBUNTU: Ubuntu-2.6.37-0.0 commit somewhere it will not woerk | 08:44 |
| apw | i generally just hand make the commit log for the firrst time there, must as smb suggested | 08:44 |
| apw | it will work the next time | 08:44 |
| tseliot | apw: I have this though: "UBUNTU: (release) Ubuntu-2.6.37-0.0 for $MYPROJECT" | 08:45 |
| tseliot | maybe "(release)" broke the regular expression or whatever it's using | 08:46 |
| apw | no its the for $MYPROJECT that broke it | 08:46 |
| tseliot | apw: oh, really? Where is it in the code? | 08:47 |
| apw | tseliot, look for printchanges | 08:48 |
| tseliot | apw: I can only see insert-changes.pl in misc | 08:49 |
| apw | rintchanges: | 08:49 |
| apw | @baseCommit=$$(git log --pretty=format:'%H %s' | \ | 08:49 |
| apw | awk '/UBUNTU: '".*Ubuntu-$(release)-$(prev_revision)"'$$/ { print $$1; exit }'); \ | 08:49 |
| apw | git log "$$baseCommit"..HEAD | \ | 08:49 |
| apw | perl -w -f $(DROOT)/scripts/misc/git-ubuntu-log $(ubuntu_log_opts) | 08:49 |
| apw | tseliot, it is that way because we generally prefix the taging on branches | 08:50 |
| tseliot | apw: what file is that? I mean the one with printchanges | 08:50 |
| apw | UBUNTU: NBK-Ubuntu-2.6.37-1.2 | 08:51 |
| apw | normally they are like that ... | 08:51 |
| apw | tseliot, that is debian/rules/1* | 08:51 |
| apw | but grep is your friend | 08:51 |
| tseliot | apw: right, I should have used a combination of find and grep | 08:51 |
| tseliot | thanks | 08:51 |
| apw | git grep is even better | 08:52 |
| smb | tseliot, There is grep -r ;-) | 08:52 |
| tseliot | ah | 08:52 |
| tseliot | apw, smb: adding a simple .* to the regular expression did it :) | 08:53 |
| apw | yeah thats fine for your bracnch, a bit risky for main | 08:53 |
| tseliot | lazyness FTW :) | 08:53 |
| tseliot | apw: yes, it's just for my branch | 08:54 |
| tseliot | apw: BTW this doesn't seem to change insertchanges, only printchanges | 08:55 |
| apw | tseliot, insertchangs directly uses printchanges | 08:55 |
| tseliot | this saved me a lot of time | 08:55 |
| apw | have you lost the markers | 08:56 |
| tseliot | apw: I know that it should use printchanges but maybe it aborts the operation | 08:57 |
| tseliot | it = insertchanges | 08:57 |
| apw | tseliot, insertchanges needs the markers in the changelog, which get lost as soon as the first insertchanges fails to find anything | 08:57 |
| apw | you often need to get them back, git diff will show you what went away | 08:58 |
| tseliot | apw: markers? Aren't they in printchanges? | 08:59 |
| apw | there are three lines of markers in the changelog, added by startnewrelease | 09:00 |
| apw | which are removed and replaced by insertchanges | 09:00 |
| apw | is they are not there, it cannot find the right place to put the output | 09:00 |
| tseliot | apw: oh, I didn't use startnewrelease for the changelog | 09:01 |
| apw | theres your problem | 09:01 |
| tseliot | right | 09:02 |
| tseliot | apw: http://kernel.ubuntu.com is public, isn't it? Does it support private branches? | 09:24 |
| apw | tseliot, define private, as in secret and must be kept hidden? | 09:31 |
| tseliot | apw: as in accessible only to canonical employees | 09:31 |
| tseliot | apw: and hidden | 09:32 |
| apw | then zinc is not an appropriate venue | 09:32 |
| apw | there are non-canonical people who can login for example | 09:32 |
| tseliot | s/to/by/ | 09:32 |
| apw | there is an oem repo somewhere | 09:32 |
| apw | whihc you should ask about on #hwe | 09:33 |
| tseliot | apw: ok, thanks | 09:33 |
| smb | cking, apw https://wiki.canonical.com/UbuntuPlatform/Rally/Natty | 09:36 |
| cking | smb, ta | 09:40 |
| kraut | moin | 09:50 |
| apw | https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty | 09:52 |
| === doko__ is now known as doko | ||
| akheron | just stumbled upon bug #154271 | 13:31 |
| ubot2 | Launchpad bug 154271 in xen-3.3 (Ubuntu) (and 2 other projects) "xenU sending too big packets (affects: 2) (heat: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/154271 | 13:31 |
| akheron | does anyone have a clue of what could cause this? | 13:31 |
| smb | gutsy??? | 13:33 |
| akheron | the kernel in xen domU sends too big IP packet, router asks to fragment, kernel sends a smaller one, the other end of the connection acks, and then the kernel sends too big packet again | 13:33 |
| akheron | smb: no, I have this with a lucid domU | 13:33 |
| apw | well if it is a kernel issue then it should really be files against the kernel ?!? | 13:34 |
| akheron | domU is 2.6.32-22-generic-pae, dom0 is lenny's 2.6.26 something | 13:34 |
| akheron | xen 3.3 | 13:35 |
| akheron | apw: I don't really know where the bug is but seems kernel to me | 13:35 |
| smb | Hm, in Hardy there has been some F-RTO issues. Though I thought 2.6.26 should have those fixed. | 13:35 |
| apw | smb, the tcpdump seems to show packats being sent >MSS | 13:36 |
| akheron | I can send more tcpdumps if someone wants to | 13:36 |
| akheron | just figured out today why my domUs have been sending data VERY slowly | 13:36 |
| apw | akheron, i assume the ethtool -K tx off works for you ? | 13:37 |
| akheron | apw: yes, fixes it completely | 13:37 |
| akheron | but I don't understand why some tx checksumming would matter | 13:37 |
| apw | akheron, well you are handing off processing to the 'hardware' which presumably is the xen virtualised driver ... and perhaps its utterly broken | 13:39 |
| akheron | ah, ok | 13:39 |
| apw | i've documented the work-around prominently in the description and added a task for the kernel | 13:39 |
| akheron | so you think the bug is in the dom0 kernel then? | 13:40 |
| akheron | we're using debian kernels there are ubuntu doesn't ship them, afaik | 13:40 |
| akheron | I'm not the system admin :) | 13:40 |
| apw | akheron, no i suspect it is in the domU kernel as its only there that switching it | 13:41 |
| apw | makes a difference | 13:41 |
| smb | Well dom0 would be the one supplying the "hw" | 13:41 |
| smb | Last dom0 we did was hardy | 13:41 |
| akheron | smb: yes, that's what I thought also | 13:41 |
| apw | smb, not necessarily, as this is logically bridged | 13:42 |
| apw | intermediate hops do not normally change the package they just ship it along | 13:42 |
| apw | and as the change of config is on the domU, and that change should be a no-op from the view of outside the domU | 13:42 |
| apw | it seems likely it should be the domU which is breaking things | 13:42 |
| smb | But as you say you change the tx offloading | 13:43 |
| apw | but that is tx offloading in the domU kernel, i can only offload it to the driver, and that is still in my domU | 13:43 |
| smb | hm | 13:43 |
| apw | it is possible that the offloading means that the dom0 does the summing instead, but that does seeem odd to me | 13:44 |
| tgardner | apw, wouldn't that imply para-virt ops? I'm pretty sure a DomU of that vintage wasn't that smart. | 13:45 |
| apw | akheron, what sort of fake ethernet is being used in the domU | 13:45 |
| akheron | I'm just looking | 13:45 |
| apw | tgardner, it is a lucid domU | 13:46 |
| akheron | xen_netfront | 13:46 |
| tgardner | oh, I thought I saw Hardy mentioned | 13:46 |
| akheron | tgardner: the bug is very old | 13:46 |
| smb | well ii read correctly this is since gutsy | 13:46 |
| apw | smb, yep i mean new kernels are still broke, or its dom0 yes | 13:49 |
| smb | Yeah. Quite odd | 13:49 |
| akheron | it seems to me that xen has some weird checksum offloading system | 13:56 |
| akheron | now that I'm looking, I can find many pages with google that suggest to disable tx offloading | 13:58 |
| apw | /* We need checksum offload to enable scatter/gather and TSO. */ | 13:59 |
| === zul is now known as ep | ||
| === ep is now known as zul | ||
| apw | it seems once we turn off the tx sum offload, we stop using scatter gather and TSO whatever the latter is | 13:59 |
| apw | dev->mtu = ETH_DATA_LEN; | 14:00 |
| apw | heh but what it does do ... is immediatly do that | 14:00 |
| apw | oh ignore me | 14:00 |
| tgardner | apw, isn't there a sysfs way to cap mtu ? | 14:00 |
| smb | apw, Where the heck are you looking? Latest code? | 14:00 |
| apw | tgardner, yep and that is set as far as i can see, and when it starts SG mode it ignores it and breaks everything | 14:01 |
| tgardner | apw, hmm, bad news | 14:01 |
| apw | smb, lucid domU support | 14:02 |
| apw | static int xennet_change_mtu(struct net_device *dev, int mtu) | 14:02 |
| apw | { | 14:02 |
| apw | int max = xennet_can_sg(dev) ? 65535 - ETH_HLEN : ETH_DATA_LEN; | 14:02 |
| apw | if (mtu > max) | 14:02 |
| apw | return -EINVAL; | 14:02 |
| apw | dev->mtu = mtu; | 14:02 |
| apw | return 0; | 14:02 |
| apw | } | 14:02 |
| apw | that seems to allow MTU to clamp close to 64k in scatter-gather mode, turning off tx csum also turns that off | 14:02 |
| apw | i suspect that when csum is turned on the dom0 is meant to do something meaningful with the packets before pushing them out onto the wire | 14:03 |
| apw | and i suspect it is not | 14:03 |
| apw | if (xenbus_scanf(XBT_NIL, np->xbdev->otherend, "feature-sg", | 14:04 |
| apw | "%d", &val) < 0) | 14:04 |
| apw | val = 0; | 14:04 |
| apw | if (!val) | 14:04 |
| apw | return -ENOSYS; | 14:04 |
| apw | does that error condition seem inverted to anyone? if we are unable to lookup feature-sg surly we should assume we have not got it, not assume we have ? | 14:04 |
| akheron | if scanf fails, val = 0 and if val == 0, return -ENOSYS | 14:05 |
| akheron | looks correct to me | 14:05 |
| apw | doh just my eyes, thanks | 14:05 |
| akheron | :) | 14:05 |
| apw | from what i can see i think xennet assumes we can pass large packets to the host and let it fragment and sum them | 14:06 |
| apw | and it looks like the host is not | 14:06 |
| akheron | so it's dom0 problem after all? | 14:07 |
| apw | i would lean to debugging there first yes | 14:07 |
| akheron | at least the fragmentation needed packets arrive at domU | 14:07 |
| smb | I dunno, max is not used. Its mtu in the code above | 14:07 |
| smb | And that is set to the right value | 14:07 |
| tgardner | apw, we could test your theory by fixing the mtu CAP on the domU client. | 14:08 |
| akheron | the mtu on eth0 is 1500 | 14:08 |
| apw | well i would expect that if we shove a bad packet out without fragmenting it and get a reply from an external router, i would expect us to pass that back to the domU thinking its for it | 14:08 |
| akheron | but it still sends >2900 byte packets | 14:08 |
| akheron | I can see that using tcpdump clearly | 14:08 |
| apw | right, and the MTU seems to be ignored at the domU when when DG and CSUM offloading is enabled | 14:09 |
| apw | SG even | 14:09 |
| apw | and we pass all the bits as one packet even if it was multiple skb's | 14:09 |
| akheron | doest it try to optimize domU - domU traffic inside dom0 by ignoring mtu? | 14:09 |
| akheron | because that traffic seems to work | 14:09 |
| apw | akheron, yes i think its meant to optimise by ignoring MTU during the cross domU/domH transition | 14:10 |
| apw | assuming that the dom0 will fit the result into the MTU before shoving it into the bridge at the other side | 14:10 |
| akheron | but it doesn't | 14:11 |
| apw | indeed it seems not | 14:11 |
| apw | but that seems like a dom0 issue | 14:11 |
| apw | its not clear from the interface how you would avoid having to handle that at the other end of the link | 14:11 |
| apw | akheron, one interesting test would be to disable tx offloading then turn it back on and confirm that the issue reasserts itself | 14:16 |
| apw | smb, with luck xen dom0 will be upstream by the next LTS, ie by the time hardy goes away | 14:20 |
| smb | apw, and maybe fixed. Though (and unfortunately I have not time to learn enough) lots of the interaction is done by a user-space part | 14:21 |
| apw | yeah i bet it is | 14:22 |
| apw | we have qemu for the same purpose in kvm | 14:22 |
| smb | I believe they use qemu too | 14:22 |
| === yofel_ is now known as yofel | ||
| smb | apw, Hm, just reading that qemu is more likely used for HVM domUs not for the PV domUs (which use a xennet-backend (which is maybe in the hypervisor code)) | 14:34 |
| === bjf[afk] is now known as bjf | ||
| bjf | https://kernel-tools.canonical.com/srus.html | 15:55 |
| bjf | https://kernel-tools.canonical.com/queues.html | 15:56 |
| tgardner | bjf, did mumble die on us? | 16:01 |
| cking | died on me | 16:01 |
| JFo | yep | 16:01 |
| smb | Seems to have for me | 16:01 |
| bjf | yup | 16:01 |
| JFo | diead for everyone it seems | 16:01 |
| smb | And it looks like canonical irc as well | 16:01 |
| JFo | yep | 16:01 |
| tgardner | just came back | 16:01 |
| cking | me too | 16:01 |
| cking | and my email | 16:01 |
| === diwic is now known as diwic_afk | ||
| ubuntuuser | Hi | 16:20 |
| ubuntuuser | I have run into some issues between my SATA-controller (VT6420) and my new Western Digital Green Power disk (WD10EARS) | 16:21 |
| ubuntuuser | There seems to be a fix for it | 16:21 |
| ubuntuuser | http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/02db8575ded42ab1 | 16:21 |
| ubuntuuser | what can I do to help get the patch in ubuntu's kernel as soon as possible? | 16:22 |
| tgardner | ubuntuuser, this seems like a stable updates sort of patch. | 16:26 |
| bcurtiswx_ | im going to assume you've gotten this question a lot recently and apologize if its overkill. Does Ubuntu plan on grabbing the ~200 line kernel patch that sig improves things for Natty? | 16:27 |
| ogasawara | bcurtiswx_: http://askubuntu.com/questions/13562/how-do-we-get-this-magic-performance-boosting-200-line-patch | 16:28 |
| bcurtiswx_ | ogasawara, :) muchas gracias | 16:28 |
| manjo | have you guys looked at https://status.canonical.com/doc/faq ? | 16:34 |
| apw | manjo, how does microblogging help us? i have enough of that in my life already | 16:38 |
| * apw pokes manjo | 16:46 | |
| manjo | apw, on a call | 16:47 |
| apw | so multi-task :) | 16:47 |
| JFo | why must headaches all act differently? This one refuses to let my eyes focus for very long :-/ | 16:51 |
| JFo | that is my QOTD | 16:51 |
| ubuntuuser | thanks tgardner, I am new to bug reporting/patching etc, can I do something/do I have to file a bug report? | 17:00 |
| manjo | ubuntuuser, you could file a bug and add a comment pointing to that patch | 17:04 |
| === jdstrand is now known as jdstrand_ | ||
| apw | JFo, different causes, that one is likely eye strain related | 17:26 |
| JFo | could be | 17:27 |
| JFo | I think it is still lack of sleep related | 17:27 |
| JFo | either way, it sucks | 17:27 |
| apw | generally being awake is signalled by eyes not closed and not resting | 17:28 |
| ogra_ac | tgardner, hmm, Bug 673509 is no duplicate of bug 673504 | 17:29 |
| ubot2 | Launchpad bug 673509 in linux (Ubuntu) "Beagleboard-xm chooses a new IP address on each boot (dup-of: 673504)" [Undecided,Confirmed] https://launchpad.net/bugs/673509 | 17:29 |
| ubot2 | Launchpad bug 673504 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "Pandaboard chooses a new IP address on each boot (affects: 2) (dups: 1) (heat: 26)" [High,Fix committed] https://launchpad.net/bugs/673504 | 17:29 |
| ogra_ac | *of Bug 673509 | 17:29 |
| tgardner | ogra_ac, its already been pointed out to me | 17:29 |
| ogra_ac | tgardner, but now we have verification tags on both | 17:29 |
| ogra_ac | after the disaster yesterday i'd like to avoid that uploads get wiped from -proposed unconditionally through wrong tagging | 17:30 |
| tgardner | ogra_ac, ti-omap4 is building. | 17:30 |
| ogra_ac | yes, and the beagleboard bug has a verification-needed tag now | 17:30 |
| tgardner | ogra_ac, that wasn't a disaster, merely a minor hiccup | 17:30 |
| ogra_ac | well, tell that to tobin who moans about having to spend a week to find community testers | 17:31 |
| apw | heh well we do want to know we arn't bricking boards right ? | 17:38 |
| ogra_ac | apw, well, hard to brick a board if you apply the patch to the wrong kernel :P | 17:42 |
| ogra_ac | i set the bug back to proper status so we can track verification as soon as the next linux package goes up | 17:43 |
| jewsucanuse | what rc is the scheduler patch er... scheduled for? | 18:12 |
| tgardner | jewsucanuse, http://askubuntu.com/questions/13562/how-do-we-get-this-magic-performance-boosting-200-line-patch | 18:14 |
| jewsucanuse | thx tim | 18:14 |
| Sarvatt | jewsucanuse: 2.6.38-rc1 most likely unless some magic happens | 18:14 |
| tgardner | apw, how do I get .bashrc to execute on login? Since trashing /home on tangerine I can't seem to automatically get it sourced. | 18:14 |
| jewsucanuse | natty is still scheduled for .38 right? | 18:14 |
| apw | tgardner, i believe different ones get souced depending if the connection is interactive or not, i always have to add an echo NAME to .bashrc .bash_login and .profile in my home and try it out to figure out which ones get loaded when | 18:18 |
| tgardner | apw, ah! Its .profile that sources .bashrc | 18:22 |
| === zul_ is now known as zul | ||
| ubuntuuser | ok i will file a bug, thanks tgardner, manjo | 18:50 |
| JanC | apw: it's documented in 'man bash' and 'info bash', you know... ;) | 18:53 |
| apw | JanC, yeah it is, but it uses words that make it much easier to just try it and see :) | 18:53 |
| JanC | eh, it seems like it's plain English to me, but I'm not a native speaker | 18:56 |
| === xfaf is now known as zul | ||
| ubuntuuser | ok I have reported the bug (676644) sorry if it is not quite up to the usual standards, I am new to this ;) | 19:25 |
| * tgardner lunches | 19:29 | |
| hallyn | to replicate a kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/, do i just apply the 3 patches there and hit 'go'? | 19:29 |
| * hallyn wants to get resume on his netbook working! | 19:30 | |
| tgardner | hallyn, why not try the kernel in https://launchpad.net/~kernel-ppa/+archive ? | 19:31 |
| tgardner | its based on 2.6.37-rc2 (and is still cooking) | 19:32 |
| === tgardner is now known as tgardner-afk | ||
| JanC | ubuntuuser: if you mention LP bugs on IRC, use something like: bug 676644 | 19:44 |
| ubot2 | Launchpad bug 676644 in linux (Ubuntu) "sata-via: read errors, slowdowns with VIA VT6420 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/676644 | 19:44 |
| JanC | see why? ;) | 19:44 |
| ubuntuuser | k thanks JanC | 19:45 |
| hallyn | tgardner-afk: that kernel doesn't work for me :) | 19:51 |
| hallyn | tgardner-afk: so i wanna tweak it to try and make it work again | 19:52 |
| JanC | ubuntuuser: and you can add useful info for the developers to your bug with the command "apport-collect 676644" (not sure if that's still needed if there is a patch available already though) | 19:53 |
| ubuntuuser | JanC: I'll look into it, I've just looked for some more information about the patch&bug, now I am not so sure it is what I am experiencing... A hardware issue is very unlinkely however, as I have switched out every part of the chain. | 19:55 |
| === tgardner-afk is now known as tgardner | ||
| tgardner | hallyn, whats missing frmo that kernel that _is_ in the mainline build? Or were you planning to patch the mainline? | 20:00 |
| ubuntuuser | goodbye to all, thank you | 20:03 |
| hallyn | tgardner: well, i want to debug it. | 20:05 |
| hallyn | tgardner: in the lucid kernel, resume worked | 20:05 |
| hallyn | in maverick kernel AND In upstream, it fails | 20:05 |
| hallyn | i'm kinda hoping i can find an easy fix | 20:05 |
| tgardner | hallyn, bummer. there are a lot of commits between lucid and maverick. | 20:06 |
| hallyn | yeah | 20:06 |
| hallyn | i did open bug 674075, but am figuring since it's broken upstream, there's not much hope :) | 20:07 |
| ubot2 | Launchpad bug 674075 in linux (Ubuntu) "Maverick won't resume (lucid will) on Lenovo S10-3 (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/674075 | 20:07 |
| tgardner | hallyn, which Broadcom driver are you using? The hybrid driver? | 20:11 |
| hallyn | 'wl' i guess | 20:15 |
| hallyn | (accoding to lspci -v) | 20:16 |
| * jjohansen -> lunch | 20:17 | |
| tgardner | hallyn, since its a binary blob, try 'modprobe -r wl' before suspending. | 20:17 |
| tgardner | you might also try 'rfkill bluetooth' | 20:17 |
| hallyn | no bluetooth on this thing it seems (i found out the hard way yesterday when i was expecting to use headset to mumble :) | 20:18 |
| hallyn | i'll try the modprobe -r in a few mins, thanks | 20:18 |
| dany_ | hi all | 20:32 |
| dany_ | hi guys | 20:48 |
| tgardner | ogasawara, shall I reset Lucid master-next back to its original HEAD ? | 20:48 |
| ogasawara | tgardner: nah, just about to push. want to do a quick test build first. | 20:49 |
| tgardner | ogasawara, but you're gonna clobber HEAD, right? | 20:49 |
| ogasawara | tgardner: I'm just gonna force the push over the existing master-next | 20:49 |
| ogasawara | tgardner: right | 20:49 |
| tgardner | ogasawara, ack. lemme know when cause I've a couple patches to drop in | 20:49 |
| ogasawara | tgardner: I just pushed. if there's a build failure, I'll fix it up in a subsequent commit. | 20:52 |
| ogasawara | tgardner: I was also gonna drop in your patch for bug 628776, unless you beat me to it | 20:54 |
| ubot2 | Launchpad bug 628776 in linux (Ubuntu Maverick) (and 2 other projects) "HP NC511i Driver (be2net and be2scsi) is missing in kernel module udebs (affects: 2) (heat: 54)" [Low,Fix released] https://launchpad.net/bugs/628776 | 20:54 |
| tgardner | ogasawara, there are 2 patches for 628776. I'm just gonna do a test build then mark the bug verification-done | 20:55 |
| tgardner | since its verifiable by inspection | 20:55 |
| ogasawara | tgardner: cool | 20:55 |
| hallyn | tgardner: wl is apparently not the culprit. at least not the only one | 21:03 |
| tgardner | hallyn, well, if the bug is still upstream then you're likely gonna have bisect it | 21:05 |
| hallyn | tgardner: right | 21:09 |
| hallyn | tgardner: hence my original question. i recon' i'll just try it | 21:10 |
| === tgardner is now known as tgardner-afk | ||
| * jjohansen running an errand | 22:06 | |
| dany_ | no one? | 22:13 |
| === ogra_ac_ is now known as ogra_ac | ||
| apw | dany_, if you have a question ask it ... | 22:56 |
| dany_ | apw: I said before, I'll copy again := | 22:57 |
| dany_ | :) | 22:57 |
| dany_ | I get this error: gcc -g -O2 -Wall -Wunused -o .libs/dc1394_vloopback dc1394_vloopback.o affine.o -lm ../libdc1394/.libs/libdc1394_control.so /usr/lib/libraw1394.so | 22:57 |
| dany_ | ../libdc1394/.libs/libdc1394_control.so: undefined reference to `raw1394_set_iso_handler' | 22:57 |
| dany_ | I'm installing an old version of libdc1394 | 22:57 |
| dany_ | the 1.2 one | 22:57 |
| dany_ | I think that it doesn't see the raw library that is installed in my system | 22:57 |
| dany_ | Can you tell me how can I say to libdc1394 (there is a configure file) | 22:57 |
| dany_ | to see the libraw? | 22:57 |
| dany_ | tgardner: wl is apparently not the culprit. at least not the only one | 22:57 |
| === johanbr_ is now known as johanbr | ||
| === bjf is now known as bjf[afk] | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!