| 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. | 00:00 |
|---|---|---|
| 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 | 03:59 |
| CarlFK | what little bit of magic do I need to hook that up? | 04:00 |
| CarlFK | oh crap - sorry, wrong chan | 04:00 |
| === nijaba` is now known as nijaba | ||
| === anubhav_away is now known as anubhav | ||
| === anubhav_away is now known as anubhav | ||
| 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:52 |
| ubot3 | bugzilla.kernel.org bug 12110 in Wireless "ath9k causes computer to hang after long data transmissions" [Normal,Closed: code_fix] | 13:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| rtg | jcastro: hang on a sec, I'll find the changelog for Intrepid LBM | 13:57 |
| 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:58 |
| rtg | jcastro: there is a bug report associated with LBM, so let smb_tp know if tehre are issues. | 13:59 |
| jcastro | nod | 13:59 |
| 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:00 |
| rtg | jcastro: yep, the wireless updates tend to be inter-related | 14:02 |
| jcastro | rtg: ok so then, if someone is having wireless problems then they should probably try lbm before reporting a bug. | 14:04 |
| 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:05 |
| jcastro | I'll bring it up to jono, perhaps there is something we can in the community to spread the word | 14:06 |
| === balbir_ is now known as bsa | ||
| === bsa is now known as bsarora | ||
| 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:30 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:46 |
| rtg | IntuitiveNipple: ah, you might have to consult with my git expert apw. I've encountered the same issue occasionally. | 14:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 14:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| apw | oh miss understood | 15:05 |
| 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:06 |
| 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:07 |
| 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:09 |
| 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:10 |
| 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:11 |
| apw | ahh yes, so name-rev must be being deprecated | 15:13 |
| dandel | 0o | 15:19 |
| 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:24 |
| IntuitiveNipple | Can script that nicely | 15:25 |
| === lieb_ is now known as lieb | ||
| 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:36 |
| 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 | 17:38 |
| apw | IntuitiveNipple, that seems overkill if the absolute path is there and is good | 18:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| IntuitiveNipple | I always try to generalise my scripts to cope with unanticipated future usage | 18:27 |
| 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:18 |
| rtg | maxb: Jaunty? its likely a hold-over from Hardy | 20:20 |
| maxb | ah. Are they being retained in case of future need, do you suppose? | 20:21 |
| rtg | maxb: well, I didn't do it with malice aforethought, but it _does_ seem like a good idea. | 20:22 |
| 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:23 |
| rtg | on second thought, it shouldn't even be building a udeb. | 20:24 |
| rtg | its not seeded by the installer AFAIK | 20:24 |
| * Nafallo wonders what happened with USB in Jaunty | 21:10 | |
| NCommander | Nafallo, ? | 21:14 |
| 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:15 |
| 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:25 |
| JanC | uhm, I think that after an earlier boot into recovery mode a system restart shouldn't start recovery mode again... | 21:37 |
| JanC | I guess this is because kexec gets handed the same boot parameters again... | 21:39 |
| 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:42 |
| 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:44 |
| 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:45 |
| 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] | 21:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!