[00:00] <dandel> 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] <CarlFK> ... error while loading shared libraries: libgif.so.4: cannot open shared object file: No such file
[03:59] <CarlFK> carl@dv67:~/src/pdf417_enc.4.4$ locate libgif.so.4 
[03:59] <CarlFK> /usr/lib/libgif.so.4
[04:00] <CarlFK> what little bit of magic do I need to hook that up?
[04:00] <CarlFK> oh crap - sorry, wrong chan
[13:52] <jcastro> 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] <ubot3> Malone bug 289356 in linux "ath9k causes system lockup" [Undecided,Confirmed] https://launchpad.net/bugs/289356
[13:53] <ubot3> bugzilla.kernel.org bug 12110 in Wireless "ath9k causes computer to hang after long data transmissions" [Normal,Closed: code_fix] 
[13:54] <rtg> jcastro: try LBM ? Its about as current as it gets
[13:54] <jcastro> I don't actually have the problem, I am checking for someone, but I can recommend that
[13:55] <dandel> apw, they asked for the log messages again lol. ( and it's already up there )
[13:55] <rtg> 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] <jcastro> 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] <jcastro> 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] <rtg> jcastro: hang on a sec, I'll find the changelog for Intrepid LBM
[13:58] <rtg> jcastro: https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.27 , compat-wireless updated as of March 4.
[13:58] <jcastro> ok cool, I will recommend that then, thanks!
[13:59] <rtg> jcastro: there is a bug report associated with LBM, so let smb_tp know if tehre are issues.
[13:59] <jcastro> nod
[14:00] <jcastro> 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] <rtg> jcastro: yep, the wireless updates tend to be inter-related
[14:04] <jcastro> rtg: ok so then, if someone is having wireless problems then they should probably try lbm before reporting a bug.
[14:05] <rtg> jcastro: that is what I'd _like_ them to do, but most folks don't know about LBM
[14:05] <jcastro> yeah, I usually don't need anything in LBM so I haven't been following it
[14:06] <jcastro> I'll bring it up to jono, perhaps there is something we can in the community to spread the word
[14:30] <IntuitiveNipple> 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] <ubot3> Malone bug 335507 in netspeed "netspeed applet will not measure wired" [Undecided,New] https://launchpad.net/bugs/335507
[14:36] <rtg> 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] <IntuitiveNipple> 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] <rtg> huh, I haven't delved into the guts of a net driver recently.
[14:38] <IntuitiveNipple> I know... it's one of those "it changed two years ago and no-one announced it" things
[14:38] <IntuitiveNipple> http://kerneltrap.org/mailarchive/linux-netdev/2009/1/27/4827604/thread
[14:46] <IntuitiveNipple> 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] <IntuitiveNipple> 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] <rtg> IntuitiveNipple: ah, you might have to consult with my git expert apw. I've encountered the same issue occasionally.
[14:56] <IntuitiveNipple> lol yeah... I burned a few fuses trying to figure it out last night :)
[14:56] <rtg> IntuitiveNipple: I generaly get so many unused objects that I have to prune now and then
[14:57] <IntuitiveNipple> 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] <apw> IntuitiveNipple, so you have a commit and want to know the head that its part of?
[14:58] <IntuitiveNipple> apw: I'd like to see the remote name with icing on, yeah :)
[14:58] <IntuitiveNipple> I figure being once-removed via the --reference linkage might make that difficult
[14:59] <apw> IntuitiveNipple, git name-rev <sha1> tells you if the remote is in your current tree
[14:59] <apw> if its --reference, then there is no way to know as the remotes don't exists in this repo
[14:59] <IntuitiveNipple> hmmph
[15:00] <apw> but the reference is local, so you can just cd there and run the same command right
[15:00] <rtg> I usually 'git fetch' without adding a remote, so there is no way to know.
[15:01] <apw> yeah thats cirtainly annoying
[15:01] <apw> as remotes are basically zero cost i usually add one
[15:01] <rtg> typically though, I'm applying a patch immediately, so its easy to remember the reference and put it in the commit log
[15:01] <IntuitiveNipple> 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] <IntuitiveNipple> git name-rev a682604
[15:02] <IntuitiveNipple> a682604 undefined
[15:02] <apw> very linus of you
[15:02] <apw> IntuitiveNipple, that was in the linus-2.6 tree?
[15:02] <IntuitiveNipple> apw: no, the unbuntu-jaunty tree
[15:03] <IntuitiveNipple> git name-rev a682604
[15:03] <IntuitiveNipple> a682604 remotes/x86-tip/auto-sched-next~1^2~1
[15:03] <apw> apw@dm$ git name-rev a682604
[15:03] <apw> a682604 tags/v2.6.29-rc7~5^2
[15:03] <apw> though it looks to be integrated into linus' tree now
[15:04] <IntuitiveNipple> yeah, things move on. It's the general principle that would help me a lot.
[15:04] <apw> what does git name-rev --all a6... say
[15:05] <apw> oh miss understood
[15:06] <IntuitiveNipple> 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] <IntuitiveNipple> apw: git name-rev -all a... says "error: Specify either a list, or --all, not both!"
[15:07] <apw> bah, useless
[15:07] <apw> i assume its shown the nearest tip to the reference
[15:07] <IntuitiveNipple> yeah, -all is an or with commit id
[15:07] <rtg> 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] <IntuitiveNipple> 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] <apw> name-rev is about as close as it gets
[15:09] <apw> it is possible to script round git merge-base to get all places its a member of
[15:10] <IntuitiveNipple> apw: Yeah... I'll have to figure out a way to patch that to handle remotes
[15:10] <apw> well its not remotes, its alternates
[15:10] <IntuitiveNipple> or rather, references
[15:10] <IntuitiveNipple> yes
[15:10] <apw> though it printing out a reference which isn't available here is a bit strange
[15:10] <IntuitiveNipple> From a user perspective it ought to be an option of git describe
[15:11] <apw> so it'd never want to be normal behaviour
[15:11] <apw> git describe is the opposite in some senses
[15:11] <apw> its which tag is older than this commit
[15:11] <apw> git name-rev is which tag head is newer than this thing
[15:11] <IntuitiveNipple> or newer (--contains)
[15:13] <apw> ahh yes, so name-rev must be being deprecated
[15:19] <dandel> 0o
[15:24] <IntuitiveNipple> ok, found a workable solution :)
[15:24] <IntuitiveNipple> GIT_DIR=../linux-2.6/.git git name-rev a682604
[15:24] <IntuitiveNipple> a682604 remotes/x86-tip/auto-sched-next~1^2~1
[15:25] <IntuitiveNipple> Can script that nicely
[17:36] <apw> IntuitiveNipple,  there is a path to the other stoer in .git/objects/info/alternate
[17:36] <apw> or similar, you might use that in your script
[17:38] <IntuitiveNipple> 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] <apw> IntuitiveNipple, that seems overkill if the absolute path is there and is good
[18:24] <IntuitiveNipple> apw: no, because I want it to work from any repo with any alternate
[18:24] <apw> right, but i mean the absolute path is as good as a relative one
[18:24] <apw> so why do you need to common prefix munch it?
[18:25] <apw> apw@dm$ GIT_DIR=`cat .git/objects/info/alternates`/.. git name-rev a682604
[18:25] <apw> a682604 tags/v2.6.29-rc7~5^2
[18:25] <apw> why is that not always sufficient?
[18:26] <IntuitiveNipple> I'm doing some other stuff with the scripts that is based on relative path portability, that's all.
[18:26] <apw> ok
[18:27] <IntuitiveNipple> I always try to generalise my scripts to cope with unanticipated future usage
[20:18] <maxb> 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] <rtg> maxb: Jaunty? its likely a hold-over from Hardy
[20:21] <maxb> ah. Are they being retained in case of future need, do you suppose?
[20:22] <rtg> maxb: well, I didn't do it with malice aforethought, but it _does_ seem like a good idea.
[20:23] <rtg> in any case, it causes no harm
[20:23] <maxb> Pointless things annoy me. Having ascertained that they are not actually pointless, I am happy :-)
[20:24] <rtg> on second thought, it shouldn't even be building a udeb.
[20:24] <rtg> its not seeded by the installer AFAIK
[21:10]  * Nafallo wonders what happened with USB in Jaunty
[21:14] <NCommander> Nafallo, ?
[21:15] <Nafallo> it seems to default to USB1.1 or something? even for USB2 devices :-/
[21:15] <Nafallo> at least my backup here is /dead slow/
[21:25] <Nafallo> also copying data from my hardware RAID1 USB2 enclosure was ~600K/s at best.
[21:25] <Nafallo> no idea how to debug this issue though
[21:37] <JanC> uhm, I think that after an earlier boot into recovery mode a system restart shouldn't start recovery mode again...
[21:39] <JanC> I guess this is because kexec gets handed the same boot parameters again...
[21:42] <IntuitiveNipple> Nafallo: It's a general kernel problem. We've just published a resolution for it
[21:42] <IntuitiveNipple> JanC: Yes... catches me out too :p
[21:44] <JanC> 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] <IntuitiveNipple> 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] <Nafallo> IntuitiveNipple: awesome. ta :-)
[21:46] <IntuitiveNipple> 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] <ubot3> Malone bug 296710 in linux "warning: ehci_hcd loaded AFTER uhci_hcd and ohci_hcd" [Medium,Fix released]