| === doko_ is now known as doko | ||
| soren | What's the magic I need to do to get my git branch to show up on gitweb? | 13:19 |
|---|---|---|
| amitk | soren: Put it under /srv/kernel.ubuntu.com/git/soren on zinc and twiddle your fingers till the next run the script that publishes it | 13:42 |
| soren | Oh! | 13:43 |
| soren | I forgot to twiddle my thumbs. | 13:43 |
| amitk | should happen withing the hour, IIRC | 13:43 |
| soren | That's why you're the one who's on the kernel team, and not me. | 13:43 |
| soren | Oh, it's there now. \o/ | 13:43 |
| amitk | i know.. we're good at twiddling ;) | 13:44 |
| soren | amitk: By the way: Do you happen to know if it's cool for me to use zinc for hosting non-kernel git trees? | 13:44 |
| amitk | soren: I don't think we are going to bitch about non-kernel git trees in the short term, but if you (and others) are going to require it over the longer term it might makes sense to talk to IS. Afterall, zinc == kernel.ubuntu.com | 13:47 |
| soren | Cool, that's what I thought. Thanks. | 13:48 |
| rtg | soren: zinc is so underutilized right now that I doubt anyone would even notice. | 13:49 |
| soren | rtg: Heh :) | 13:49 |
| amitk | soren: these kernel git trees you published, are they for the virtual flavours? | 13:49 |
| soren | amitk: No. | 13:49 |
| soren | amitk: I want to get the packaging sorted out first. that's on my list for the sprint next week. | 13:50 |
| amitk | soren: are you going to have a different source pacakge or are you planning to build-dep on linux? | 13:51 |
| soren | b-d on linux-source. | 13:51 |
| amitk | rtg: any idea what is wrong here: | 13:51 |
| amitk | II: Checking ABI for lpia... | 13:51 |
| amitk | WW: Explicitly asked to ignore ABI, running in no-fail mode | 13:51 |
| amitk | EE: Previous or current ABI file missing! | 13:51 |
| amitk | soren: so you will maintain everything as patches? | 13:52 |
| soren | amitk: I think so. | 13:52 |
| rtg | amitk: I think I broke current git build last night , I'm working on it | 13:52 |
| soren | amitk: There are a few options... Neither appeal to me very much. | 13:52 |
| amitk | rtg: No.. this in in my lpia tree that is based off the main tree | 13:53 |
| smb_tp | amitk, might be at least the modules list and maybe the abi files for the last release are not there. Fatal even if abi changes are ignored | 13:53 |
| amitk | soren: same here. I am building an lpia tree and I don't want to maintain it as patches. | 13:53 |
| soren | amitk: I can either maintain a completely separate tree, and rebase off of your now and then... That's probably the easiest, but will force me to move around *huge* source packages. | 13:53 |
| soren | or | 13:54 |
| amitk | smb_tp: but I explicitly asked for abi to be ignored by adding debian/abi/ignore | 13:54 |
| rtg | amitk: you have to add it in each arch | 13:54 |
| soren | I can try to maintain patches and separate configs.... That gives me small source packages, but if you rebase, and my stuff fails to apply, I have to work that out rather manually, AFAICT. | 13:54 |
| amitk | soren: I am leaning towards the same solution | 13:54 |
| rtg | debian/abi/lpia/ignore | 13:54 |
| smb_tp | amitk, It seemed to me changes are ignored but the files must be there | 13:54 |
| smb_tp | amitk, I tend to just create the files by copying some older directory to the name it wants for the old abi | 13:56 |
| soren | amitk: The idea solution would be to have a separate git tree, and make it able to generate the needed patches on the fly, but... I don't know.. It's just a hassle. | 13:56 |
| soren | I'd hate to have to maintain a completely new kernel build system for this. | 13:56 |
| rtg | soren: in essence, that is what amitk is doing for lpia | 13:57 |
| amitk | soren: I should have lpia done this week. I'll try to whip up scripts to automate the rebasing. We should collaborate... | 13:57 |
| soren | amitk: Totally. I didn't know you were in the same boat. | 13:58 |
| amitk | smb_tp: I have ignore and module.ignore files in every orifice of debian/abi/<version>/lpia :-/ | 13:58 |
| soren | amitk: How are you dealing with ABI checks? | 13:58 |
| soren | Just ignoring them? | 13:58 |
| amitk | soren: currently planning to have a different abi for lpia. Need to discuss with rest of the kernel-team though... | 13:59 |
| soren | That's my intent as well. | 13:59 |
| soren | If I have to maintain my own kernel, I want to actually have the freedom to mess it up any way I please (including changing core ABI stuff). | 14:00 |
| smb_tp | amitk, I also thought this should be enough but recently I was force to just put the files with the modversions there as well until the abi checker was happy. :( | 14:01 |
| rtg | soren: which is why lpia went to its own tree, freedom to release on their schedule with changes of their choosing. | 14:01 |
| amitk | rtg: smb_tp: I have reset the abi to -1 in debian/changelog, renamed the source package to linux-lpia, regenerated contro.stub. So it is as good as the first upload. But ABI is failing... | 14:01 |
| amitk | smb_tp: then something is broken.... | 14:01 |
| soren | rtg: I see. | 14:01 |
| amitk | soren: exactly. the lpia kernel will be rebased occassionally (2-3 times during the release cycle). So we won't see too many abi bumps. | 14:02 |
| smb_tp | amitk, the message itself is also a bit unclear. it would be more helpful if it would state whether ther old or new files are thought to be missing. | 14:03 |
| soren | amitk: Cool. | 14:03 |
| rtg | amitk: debian/scripts/abi-check is pretty straightforward. instrument it to see why its bitching. | 14:03 |
| soren | amitk: Well, if you've almost got it worked out, I won't spend any time on it until next week. | 14:03 |
| soren | amitk: Oh.... You're in... London? | 14:03 |
| soren | Yes, there was the visa thing. I remember. | 14:03 |
| soren | I | 14:03 |
| amitk | soren: I hope to push out the git tree before the week is out | 14:04 |
| soren | 'm in Lexington, but at least there's some overlap in working hours anyway. | 14:04 |
| soren | amitk: Cool! | 14:04 |
| rtg | soren: know anything about file systems? Is there any file system faster at removing lots of small files then ext3? | 14:05 |
| soren | rtg: I though ext3 was supposed to be really fast at that? | 14:06 |
| amitk | rtg: IIRC, xfs and jfs are better at smaller files. | 14:07 |
| smb_tp | soren, no ext3 is slow ext4 should get better | 14:07 |
| smb_tp | xfs is what I heard too | 14:07 |
| rtg | soren: deleting a fully built kernel directory takes minutes. | 14:07 |
| smb_tp | rtg, did you mount that with noatime? | 14:07 |
| soren | xfs is slow at deletes. | 14:08 |
| smb_tp | rtg, got the feeling it is faster now... | 14:08 |
| rtg | smb_tp: relatime,errors=remount-ro | 14:08 |
| rtg | smb_tp: standard mount magic | 14:08 |
| amitk | rtg: 'rm -rf linux-dir &' :-p | 14:09 |
| rtg | amitk: yeah - but my scripts want to reuse the directory. maybe I should rename, then 'rm -rf' | 14:09 |
| smb_tp | rtg, I recently made myself a seperate fs for compiling (ok, its striped as well) and use notatime for that | 14:10 |
| amitk | rtg: mv linux-dir linux-foo; rm -rf linux-foo & | 14:10 |
| rtg | smb_tp: what does noatime do? | 14:10 |
| smb_tp | rtg, does not put an access time to a file. which is otherwise updated everytime you access a file | 14:10 |
| alex_joni | rtg: http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec73.html | 14:11 |
| smb_tp | rtg, modification time is updated though | 14:11 |
| soren | rtg: reiserfs is quite fast at deletes, too, but that sort of has maintainability issues now.. | 14:11 |
| rtg | soren: I have a reiserfs partition that I use daily for several years, in fact I created it using SuSE 6.x | 14:12 |
| soren | rtg: So that's reiser... 3? | 14:13 |
| soren | rtg: Oh, tmpfs is also rather fast at deletes. | 14:14 |
| soren | ! | 14:14 |
| rtg | soren: whatever is current in Hardy must be backward compatible. | 14:14 |
| soren | Certainly, but if the metadata format is ancient, the benchmarks, I'm looking at might be completely wrong. | 14:14 |
| soren | (remove commas as needed) | 14:14 |
| smb_tp | rtg, when we are at the real "good" advices why not ry ext2. who needs a journal for compiling... ;-) | 14:15 |
| rtg | soren: well, the real performance issue is on this screaming fast server I got from Intel. It must havea _really_ slow disk. | 14:15 |
| soren | smb_tp: Good point. ext2 is much faster than ext3 in this respect. | 14:16 |
| cking | rtg: I use ext3 with noatime,nodiratime,reservation,relatime | 14:17 |
| rtg | cking: on /home ? or a separate partition? | 14:17 |
| cking | rtg: on nearly everthing except boot | 14:18 |
| amitk | ohhh all your geeks :) | 14:18 |
| rtg | cking: the default install doesn't create a /boot partition | 14:18 |
| cking | amitk: seriously, it makes 2.347 nanoseconds difference :-) | 14:18 |
| cking | rtg: yeah - I do my own custom kind of thing | 14:19 |
| amitk | cking: now that _would_ be noticeable :) | 14:19 |
| alex_joni | hardy does realatime by default afaik | 14:20 |
| rtg | cking: how do I figure out what kind of hard drive is in this server, and how fast it is (relative to other hard drives) ? | 14:20 |
| alex_joni | rtg: hdparm -tT /dev/foo is your friend | 14:20 |
| cking | rtg: and dd is a quick way of benchmarking file I/O | 14:20 |
| alex_joni | works on software RAID too: root@main:~# hdparm -tT /dev/md0 | 14:21 |
| alex_joni | Timing cached reads: 8770 MB in 2.00 seconds = 4390.51 MB/sec :-) | 14:21 |
| cking | rtg: ..don't twiddle hdparm -X unless you are prepared to screw up your data. | 14:21 |
| rtg | /dev/sda1: | 14:21 |
| rtg | Timing cached reads: 13124 MB in 1.99 seconds = 6578.94 MB/sec | 14:21 |
| rtg | Timing buffered disk reads: 314 MB in 3.00 seconds = 104.56 MB/sec | 14:21 |
| rtg | alex_joni: that doesn't look nearly as good as yours. | 14:22 |
| cking | rtg: That's twice than what I get | 14:22 |
| rtg | cking: actually, its twice what I get on my dev box as well. | 14:23 |
| rtg | cking: alex_joni must be doing it against a tmpfs :) | 14:23 |
| cking | rtg: This is where having 64Gb of 800Mhz DDR2 and the whole of the git source cached in there is a good thing | 14:25 |
| rtg | cking: this box has 18GB. you would think that's almost enough. | 14:26 |
| amitk | rtg: thats twice what I get | 14:26 |
| smb_tp | rtg, maybe you should really use tmpfs for compiles... | 14:26 |
| rtg | amitk: it literally takes 4-5 minutes to delete these directories. I think I'll reformat for ext2 with noatime. | 14:27 |
| cking | rtg: ..I have some runes that I use: | 14:28 |
| smb_tp | rtg, maybe first try noatime only. thats just a reboot/remount | 14:28 |
| cking | I use tune2fs -O dir_index /dev/sdaX, e2fsck -D -f /dev/sdaX and mount /dev/sdaX with noatime,nodiratim,reservation | 14:30 |
| cking | make that nodiratime | 14:32 |
| soren | I haven't been paying much attention to the kernel during intrepid yet... How often do you roll new releases? Weekly-ish? | 14:38 |
| rtg | cking: what are the relative merits of tmpfs? google has some entries where folks are mounting /tmp to tmpfs. | 14:40 |
| Tophat | has the new DNS security vulnerability been patched ? | 14:40 |
| smb_tp | It's a ram-disk... | 14:40 |
| rtg | smb_tp: I know that, but will it grow as large as it needs to? | 14:41 |
| cking | rtg: It's fast - and if you have lots of memory it's useful. I suggest doing a build in a tmpfs mounted directory and it should fly.. | 14:41 |
| smb_tp | rtg, yes it should grow | 14:41 |
| amitk | rtg: you still have the lag of copying the whole kernel tree to tmpfs | 14:42 |
| cking | amitk: yeah.. how long will that take? 80 seconds? | 14:42 |
| smb_tp | rtg, http://en.wikipedia.org/wiki/TMPFS | 14:43 |
| rtg | cking: drat, it appears that its burned in. now I'm gonna have to haul that noisy thing in here where I can get at it. it least its not in my attic. | 14:43 |
| amitk | cking: I've never felt a kernel compile to be very IO-bound, except for the final linking. | 14:44 |
| smb_tp | amitk, there seem to be times in between when cpu usage goes down... | 14:46 |
| cking | amitk: vmstat 1 seems to show a lot of I/O activity - I suppose with -j 4 or more, then it will be more CPU bound and any waits on I/O will be filled by CPU activity in the build | 14:46 |
| soren | Tophat: http://www.ubuntu.com/usn/usn-622-1 | 14:47 |
| cking | amitk: at the end of the day it's either memory, CPU or disk I/O bottlenecking somewhere.. :-) | 14:47 |
| amitk | cking: true.. | 14:49 |
| Tophat | soren - have you seen any POC on this attack? | 14:50 |
| soren | no | 14:51 |
| soren | Besides, this is off-topic here. | 14:51 |
| soren | Try in #ubuntu | 14:51 |
| Ng | is alsa 1.0.17 likely to be in intrepid? | 15:39 |
| Ng | the kernel drivery bits, I mean | 15:39 |
| rtg | Ng: if not in the kernel, then we'll likely backport it in LBM | 15:41 |
| Ng | where "in the kernel" means in LUM? or is it moving to linux-image? | 15:43 |
| Ng | not that that really matters, so long as it's available, my fellow x300 users will be spared having to worry about getting sound support. thanks :) | 15:43 |
| amitk | Ng: LUM is no more, everything is in the main git tree now | 15:44 |
| rtg | Ng: ALSA is part of the core kernel. Actually, when we backport 1.0.17 (if its a superset of core kernel) it will end up in the Intrepid equivalent of LUM. | 15:44 |
| Ng | aha | 15:45 |
| Ng | atm my x300 specific LUM with an rc of 1.0.17 is a horrific mess that happens to just about work ;) | 15:46 |
| pgraner | rtg: who is the v4l driver SME? | 20:29 |
| rtg | pgraner: dunno. whats an SME? | 20:30 |
| rtg | souce maintainer extraordinaore? | 20:30 |
| pgraner | rtg: Subject Matter Expert | 20:30 |
| rtg | pgraner: ah, a new TLA | 20:31 |
| pgraner | rtg: specifically the em28xx driver | 20:31 |
| rtg | pgraner: maybe talk to jono and find out who did the filming at UDS? | 20:31 |
| rtg | em28xx being what your handy cam supports? | 20:32 |
| pgraner | rtg: no its a tv tuner.... | 20:32 |
| smb_tp | maybe mkrufky might be of help | 20:33 |
| pgraner | rtg: I'm using a Mac for the video at the sprint just for speed. | 20:33 |
| rtg | smb_tp: yeah - mkrufky is trhe hauppage dude. | 20:33 |
| mkrufky | i am back | 20:33 |
| * mkrufky catching up on backlog | 20:34 | |
| mkrufky | ok, yeah i am the guy | 20:34 |
| mkrufky | what is the question? | 20:34 |
| pgraner | smb_tp: cool.... I have a Bus 005 Device 038: ID 2040:6513 Hauppauge and I can't get hardy to recognize it | 20:34 |
| mkrufky | btw, i am moreso "the guy" because of my linuxtv affiliation rather than my hauppauge affiliation | 20:34 |
| mkrufky | hary does not support 2040:6513 out of the box | 20:34 |
| mkrufky | but it will be supported in intrepid | 20:35 |
| mkrufky | ... but you will need to grab the xc3028-v27.fw image | 20:35 |
| mkrufky | if you want to run it in hardy, you may use the mercurial repository hosted at http://linuxtv.org | 20:35 |
| pgraner | mkrufky: cool. Is the support in the alpha1/2? | 20:35 |
| mkrufky | i do not plan on backporting this one to hardy LUM | 20:35 |
| rtg | pgraner: I thought you were expressing intrepid upgrade woes the other day. | 20:35 |
| mkrufky | pgraner: it's in the 2.6.26 kernel... i have not been tracking interpid, but intrepid has 2.6.26, so thats what u need | 20:36 |
| pgraner | pgraner: I got the sound fixed, which was the big issue other than no changelog | 20:36 |
| mkrufky | TLA ? | 20:36 |
| smb_tp | three letter acronym | 20:37 |
| mkrufky | :-) ok cool | 20:37 |
| pgraner | rtg: I had to blacklist the snd_pcsp module and the cracking went bye bye | 20:37 |
| rtg | pgraner: my somewhat oblique point being, support for your device is already in Intrepid | 20:38 |
| mkrufky | ironically, however, the next gen version of the 950 is in hardy LUM | 20:41 |
| pgraner | mkrufky: what does a *** unknown tvp3e04 chip detected *** Rom ver is 12.0 mean? | 21:19 |
| mkrufky | that depends on the context | 21:20 |
| mkrufky | where did you see said message? | 21:20 |
| mkrufky | i'll assume you saw it in dmesg log | 21:20 |
| mkrufky | if so, can you paste it with some context on a pastebin somewhere ? | 21:20 |
| pgraner | mkrufky: /var/log/messages after loading the module em28xx tells me that if found a Hauppague WinTV HVR 950 | 21:21 |
| mkrufky | context ... pastebin ... | 21:21 |
| mkrufky | please show me dmesg | tail -n100 | 21:22 |
| pgraner | mkrufky: one sec different box | 21:22 |
| mkrufky | k | 21:22 |
| mkrufky | pgraner: if you do " lsmod | grep tvp " and you do NOT see tvp5150, then thats your problem | 21:23 |
| pgraner | mkrufky: its there | 21:24 |
| mkrufky | how many users ,... 1 or 0 ? | 21:24 |
| pgraner | mkrufky: http://pastebin.com/m7750bdbf | 21:27 |
| mkrufky | pgraner: tvp5150 0-005c: tvp5150am1 detected. | 21:32 |
| mkrufky | pgraner: please try a different usb port | 21:32 |
| pgraner | mkrufky: just did | 21:33 |
| pgraner | mkrufky: dmesg is still telling me the tvp3e04 is unknown with i2c i/o errors | 21:34 |
| mkrufky | did you try it? does it work? | 21:35 |
| pgraner | mkrufky: its channel scanning now | 21:37 |
| mkrufky | the error message is coming from the analog video decoder driver | 21:38 |
| mkrufky | it looks like its complaining, then attaching correctly | 21:38 |
| mkrufky | i have not seen this before | 21:38 |
| pgraner | mkrufky: ok working now, I'm seeing channels during the scan | 21:38 |
| mkrufky | it might work anyway | 21:38 |
| mkrufky | but seems strange | 21:38 |
| mkrufky | yeah, the tvp thing would not affect digital tv | 21:39 |
| mkrufky | only analog | 21:39 |
| pgraner | mkrufky: no audio as of yet | 21:41 |
| mkrufky | what do you mean , no audio? | 21:45 |
| mkrufky | if you're watching digital TV, then the audio is part of the mpeg2 stream | 21:45 |
| pgraner | mkrufky: no audio, I can play mp3s, hear the lovely login music, but nothing from the tv tuner. I'm messing with alsa settings now | 21:46 |
| mkrufky | are you watching digital tv or no? | 21:48 |
| mkrufky | if you're watching analog tv and have no audio, then i can tell you what to do | 21:48 |
| pgraner | mkrufky: I'm watching tv, don't know how to tell if its digital or not. | 21:48 |
| mkrufky | HOW are you watching tv? | 21:48 |
| mkrufky | what app? what channel? | 21:49 |
| pgraner | mkrufky: tvtime channel 5 (CSPAN) | 21:49 |
| mkrufky | ok | 21:49 |
| mkrufky | you're watching analog tv | 21:49 |
| mkrufky | in order to get audio, google "arecord aplay tvtime" | 21:49 |
| mkrufky | or google, "sox tvtime" | 21:49 |
| mkrufky | there is no TV application that does this right, unfortunately, except for mythtv | 21:50 |
| mkrufky | note: ANALOG | 21:50 |
| mkrufky | digital tv "JustWorks(tm)" | 21:50 |
| pgraner | mkrufky: ok the aplay trick worked | 21:50 |
| pgraner | mkrufky: how do I get the digital then? | 21:50 |
| mkrufky | we are sooooo off topic | 21:51 |
| pgraner | mkrufky: yea, I'll google | 21:51 |
| mkrufky | just real quick: | 21:51 |
| mkrufky | first, scan for channels using scan from dvb-apps | 21:51 |
| mkrufky | (dvb-utils from apt) | 21:51 |
| mkrufky | then azap CHANN_EL -r (-r is important) ... leave that running | 21:51 |
| mkrufky | open a new shell, run: mplayer /dev/dvb/adapter0/dvr0 | 21:52 |
| mkrufky | thats is for a basic test | 21:52 |
| mkrufky | google will give you more detailed info | 21:52 |
| mkrufky | oh, you need to drop that channels.conf file (from your scan) into ~/.azap | 21:52 |
| pgraner | mkrufky: got it thanks | 21:53 |
| mkrufky | you're welcome | 21:54 |
| mkrufky | for future reference, #linuxtv is a better venue for these questions | 21:54 |
| mkrufky | im usually in there, but i am not right now | 21:54 |
| === asac_ is now known as asac | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!