[00:00] apw, my logs complained about a few issues with memory, so i am running memtest86 on it... 4 passes so far and no errors yet. [03:59] ... error while loading shared libraries: libgif.so.4: cannot open shared object file: No such file [03:59] carl@dv67:~/src/pdf417_enc.4.4$ locate libgif.so.4 [03:59] /usr/lib/libgif.so.4 [04:00] what little bit of magic do I need to hook that up? [04:00] oh crap - sorry, wrong chan === nijaba` is now known as nijaba === anubhav_away is now known as anubhav === anubhav_away is now known as anubhav [13:52] hi, I am trying to determine if bug 289356 is the same as this bug: http://bugzilla.kernel.org/show_bug.cgi?id=12110 [13:52] Malone bug 289356 in linux "ath9k causes system lockup" [Undecided,Confirmed] https://launchpad.net/bugs/289356 [13:53] bugzilla.kernel.org bug 12110 in Wireless "ath9k causes computer to hang after long data transmissions" [Normal,Closed: code_fix] [13:54] jcastro: try LBM ? Its about as current as it gets [13:54] I don't actually have the problem, I am checking for someone, but I can recommend that [13:55] apw, they asked for the log messages again lol. ( and it's already up there ) [13:55] jcastro: LBM is where the bulk of the upstream bug fixes are appearing. I'm only backporting or cherry picking critical stuff into mainline Jaunty [13:56] rtg: how far back do you go? I am trying to find if those fixes from kernel.org would be in say, intrepid [13:56] rtg: actually, if there is a page that shows me how to dig that up so I can learn how that would be great, I don't mind doing the digging [13:57] jcastro: hang on a sec, I'll find the changelog for Intrepid LBM [13:58] jcastro: https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.27 , compat-wireless updated as of March 4. [13:58] ok cool, I will recommend that then, thanks! [13:59] jcastro: there is a bug report associated with LBM, so let smb_tp know if tehre are issues. [13:59] nod [14:00] rtg: ok so just so I understand it, at some point in the cycle you just start putting driver updates in LBM as opposed to the kernel we ship? [14:02] jcastro: yep, the wireless updates tend to be inter-related [14:04] rtg: ok so then, if someone is having wireless problems then they should probably try lbm before reporting a bug. [14:05] jcastro: that is what I'd _like_ them to do, but most folks don't know about LBM [14:05] yeah, I usually don't need anything in LBM so I haven't been following it [14:06] I'll bring it up to jono, perhaps there is something we can in the community to spread the word === balbir_ is now known as bsa === bsa is now known as bsarora [14:30] Can anyone tell me in what circumstances a network device can be active (IFF_UP) and in-use *but* its IFF_RUNNING flag is not set? Also, is it a valid state or a bug not to have IFF_RUNNING when IFF_ACTIVE *and* the interface is actually working? bug #335507 [14:30] Malone bug 335507 in netspeed "netspeed applet will not measure wired" [Undecided,New] https://launchpad.net/bugs/335507 [14:36] IntuitiveNipple: IIRC those flags are set by the network layer. Its likely a bug for the driver to mucking about with those bits. [14:37] apparently not. Just found an email about it on the linux-netdev mailing list in January from Marcel Holtmann caught out by the same thing. Apparently, now, it only is there to indicate userspace configured the interface [14:38] huh, I haven't delved into the guts of a net driver recently. [14:38] I know... it's one of those "it changed two years ago and no-one announced it" things [14:38] http://kerneltrap.org/mailarchive/linux-netdev/2009/1/27/4827604/thread [14:46] rtg: maybe you can save me some more head-ache. git. My local jaunty repo --references my local linux-2.6 repo. In the linux-2.6 repo are several remote references to track pre-mainline patches (e.g. x86-tip, linux-pci). In the jaunty repo I can "git show" a commit from any of the remotes, but I have so far not figured out how I can show *which* remote the commit is in - in other words, I need to identify which remote the commit is fro [14:46] m. I've tried all manner of git-show and lower-level plumbing but so far not found a way to do it. Any ideas? [14:55] IntuitiveNipple: ah, you might have to consult with my git expert apw. I've encountered the same issue occasionally. [14:56] lol yeah... I burned a few fuses trying to figure it out last night :) [14:56] IntuitiveNipple: I generaly get so many unused objects that I have to prune now and then [14:57] My reason is just so when I cherry-pick I can give a reference as to where the h**l it came from :) [14:57] IntuitiveNipple, so you have a commit and want to know the head that its part of? [14:58] apw: I'd like to see the remote name with icing on, yeah :) [14:58] I figure being once-removed via the --reference linkage might make that difficult [14:59] IntuitiveNipple, git name-rev tells you if the remote is in your current tree [14:59] if its --reference, then there is no way to know as the remotes don't exists in this repo [14:59] hmmph [15:00] but the reference is local, so you can just cd there and run the same command right [15:00] I usually 'git fetch' without adding a remote, so there is no way to know. [15:01] yeah thats cirtainly annoying [15:01] as remotes are basically zero cost i usually add one [15:01] typically though, I'm applying a patch immediately, so its easy to remember the reference and put it in the commit log [15:01] I don't want to add the same remote to several repos, that was the original plan, so one fetch on linux-2.6 is for all [15:02] git name-rev a682604 [15:02] a682604 undefined [15:02] very linus of you [15:02] IntuitiveNipple, that was in the linus-2.6 tree? [15:02] apw: no, the unbuntu-jaunty tree [15:03] git name-rev a682604 [15:03] a682604 remotes/x86-tip/auto-sched-next~1^2~1 [15:03] apw@dm$ git name-rev a682604 [15:03] a682604 tags/v2.6.29-rc7~5^2 [15:03] though it looks to be integrated into linus' tree now [15:04] yeah, things move on. It's the general principle that would help me a lot. [15:04] what does git name-rev --all a6... say [15:05] oh miss understood [15:06] The scenario is, I'm chasing some bug report, see some mailing-list mention of a patch that may help, search the repo for a commit that matches the patch, and try it. If it works, it'd be nice to be able to generate the patch (git format patch ...) and include the originating remote [15:06] apw: git name-rev -all a... says "error: Specify either a list, or --all, not both!" [15:07] bah, useless [15:07] i assume its shown the nearest tip to the reference [15:07] yeah, -all is an or with commit id [15:07] IntuitiveNipple: If I'm cherry-picking, I always use the '-x' option. If its not frmo Linus tree, then I also add the git URL in the commit log. [15:09] rtg: Yeah, I do that too. This is just a nice way for me to check where a patch came from. I'm juggling about 20 different bugs a day, so I flick between them based on inspiration or research, so when I finally find a patch that fixes something, I may have forgotten the context. It'd be nice to have one simple command to tell me :) [15:09] name-rev is about as close as it gets [15:09] it is possible to script round git merge-base to get all places its a member of [15:10] apw: Yeah... I'll have to figure out a way to patch that to handle remotes [15:10] well its not remotes, its alternates [15:10] or rather, references [15:10] yes [15:10] though it printing out a reference which isn't available here is a bit strange [15:10] From a user perspective it ought to be an option of git describe [15:11] so it'd never want to be normal behaviour [15:11] git describe is the opposite in some senses [15:11] its which tag is older than this commit [15:11] git name-rev is which tag head is newer than this thing [15:11] or newer (--contains) [15:13] ahh yes, so name-rev must be being deprecated [15:19] 0o [15:24] ok, found a workable solution :) [15:24] GIT_DIR=../linux-2.6/.git git name-rev a682604 [15:24] a682604 remotes/x86-tip/auto-sched-next~1^2~1 [15:25] Can script that nicely === lieb_ is now known as lieb [17:36] IntuitiveNipple, there is a path to the other stoer in .git/objects/info/alternate [17:36] or similar, you might use that in your script [17:38] apw: Yes, that is what I'm doing... actually it has got quite sophisticated... It takes the pwd and <.git/objects/info/alternate and isolates the common path then builds a relative path from pwd to the alternate and inserts that into GIT_DIR [18:23] IntuitiveNipple, that seems overkill if the absolute path is there and is good [18:24] apw: no, because I want it to work from any repo with any alternate [18:24] right, but i mean the absolute path is as good as a relative one [18:24] so why do you need to common prefix munch it? [18:25] apw@dm$ GIT_DIR=`cat .git/objects/info/alternates`/.. git name-rev a682604 [18:25] a682604 tags/v2.6.29-rc7~5^2 [18:25] why is that not always sufficient? [18:26] I'm doing some other stuff with the scripts that is based on relative path portability, that's all. [18:26] ok [18:27] I always try to generalise my scripts to cope with unanticipated future usage [20:18] Hi, the lbm source builds an empty headers deb and an empty udeb. Is there a reason, or would a patch to stop building those be useful? [20:20] maxb: Jaunty? its likely a hold-over from Hardy [20:21] ah. Are they being retained in case of future need, do you suppose? [20:22] maxb: well, I didn't do it with malice aforethought, but it _does_ seem like a good idea. [20:23] in any case, it causes no harm [20:23] Pointless things annoy me. Having ascertained that they are not actually pointless, I am happy :-) [20:24] on second thought, it shouldn't even be building a udeb. [20:24] its not seeded by the installer AFAIK [21:10] * Nafallo wonders what happened with USB in Jaunty [21:14] Nafallo, ? [21:15] it seems to default to USB1.1 or something? even for USB2 devices :-/ [21:15] at least my backup here is /dead slow/ [21:25] also copying data from my hardware RAID1 USB2 enclosure was ~600K/s at best. [21:25] no idea how to debug this issue though [21:37] uhm, I think that after an earlier boot into recovery mode a system restart shouldn't start recovery mode again... [21:39] I guess this is because kexec gets handed the same boot parameters again... [21:42] Nafallo: It's a general kernel problem. We've just published a resolution for it [21:42] JanC: Yes... catches me out too :p [21:44] wouldn't it be possible to do a complete reboot in case the "current" boot is based on a "recovery" option in grub? [21:45] I think it is something the scripts should detect and handle. I think a check for 'single' in /proc/cmdline would do it [21:45] IntuitiveNipple: awesome. ta :-) [21:46] Nafallo: There's a workaround involving adding the USB modules in the correct order to the initrd, until the new kernel is in the archives https://bugs.edge.launchpad.net/linux/+bug/296710 [21:46] Malone bug 296710 in linux "warning: ehci_hcd loaded AFTER uhci_hcd and ohci_hcd" [Medium,Fix released]