[00:00] Greetings MOTUs and MOTUettes, I ask you kindly to please review my newly uploaded version of Me TV. I'm still awaiting my first advocate. See http://revu.tauware.de/details.py?upid=712. [00:00] jdong, interesting bug [00:01] jdong: It doesn't seem to stop, no. [00:01] i'm not really sure. i can't think of anything that we are doing that would affect said behavior [00:01] StevenK: strace look similar? [00:01] StevenK: can you get me an strace without any uploads/downloads going? [00:01] superm1: can you confirm his bug though? [00:01] jdong, not right now. i'll subscribe to it and try to take a look when i get to a machine with xvmc [00:02] jdong: Sure [00:02] Hi, how can I tell pbuilder to fetch build dependencies from universe too? ( I have added Section: universe/python ...) [00:03] jdong: Mailed [00:05] and COMPONENTS="main restricted universe multiverse" in .pbuilderrc [00:10] Any MOTU with a DVB card, I'd especially appreciate! [00:10] StevenK: hmm and you say these strace items keep CPU at what percentage? [00:11] jdong: ~20% [00:11] StevenK: no difference between whether window is open or closed? [00:11] jdong: I usually keep it minimised [00:11] frenchy: I've got me a dvb card, and reception to rubbish to use it :( [00:12] RAOF: Send it here, I have great reception. :-P [00:12] * jdong compares with his strace [00:14] StevenK: hmm my strace looks almost identical but no CPU usage :-/ [00:14] StevenK: and the cpu usage is coming out of KTorrent's process? [00:15] jdong: At the moment it's coming from cc1 :-) [00:15] jdong: When this build finishes, I'll double check with top [00:15] StevenK: LOL :) [00:15] StevenK: you don't have an indexing daemon crawling either .kde/share/ or your torrent download dir, do you? [00:15] RAOF: Sorry to hear that, I've built myself a DVB application for GNOME and I was trying to get some feedback on it. [00:16] jdong: Probably. I haven't disabled tracker, because it hasn't gotten in my way [00:16] RAOF: I was talking to a guy in Germany who got it to work with a spoon. [00:17] StevenK: :-/ well see if tracker is the root cause [00:17] RAOF: So your DVB-T also ... excellent ... Germany/Spain/Australia? [00:17] s/your/you're/ [00:18] frenchy: Australia. And I have *some* reception. Just not enough to replace my analog TV with a mythbox. [00:18] RAOF: I'm in Canberra. [00:19] RAOF: Get a better antenna? [00:19] jdong: top still points to ktorrent [00:19] In Soviet Russia, better antenna gets YOU [00:19] Boo, hiss [00:19] lol [00:19] StevenK: :-/ ktorrent is using 20% CPU idling? :( [00:19] jdong: Right [00:19] StevenK: what kind of CPU are we talking about? [00:20] 12214 steven 15 0 306m 46m 20m S 13.9 3.1 5:15.76 ktorrent [00:20] StevenK: I'm using the flat's external aerial. All my internal antennae haven't done any better. [00:20] jdong: A 3GHz Celeron [00:20] (in long mode) [00:20] StevenK: hmm I'm pretty stumped then; your strace looks identical to mine... [00:21] Okay, so it's because ktorrent sucks. :-) [00:21] jdong: Maybe x86-64 has a worse futex implementation? [00:21] RAOF: Anyway, I'd appreciate your feed back sometime. [00:21] RAOF: that is possible [00:21] can anyone reproduce on x86-64 too? :D [00:25] frenchy: I'd be happy to give it. URL? === chuck__ is now known as zul [00:27] hey all [00:27] how many packages are there in ubuntu? [00:28] nevermind [00:28] 23518 packages [00:30] effie_jayx: and those are not enough :-P [00:35] effie_jayx: depends on release, if you're counting just source packages, and what arch if not :-) [00:37] ahhh cool [00:37] Sorry, I sent it out a request for review a while ago. Here it is again in case you missed it. [00:37] Greetings MOTUs and MOTUettes, I ask you kindly to please review my newly uploaded version of Me TV. I'm still awaiting my first advocate. See http://revu.tauware.de/details.py?upid=712. [00:38] If you're not a MOTU then maybe you just ignored it. I'd still really appreciate your feedback. [00:41] frenchy: Oooh, it's a request for review, rather than a "try out my cool stuff" :) [00:41] RAOF: I've gotta go but flick me an email with any comments, I'd really appreciate them. [00:42] frenchy: I'll see if I can get around to it. [00:42] RAOF: Is there something that I need to say? [00:43] RAOF: I'll be back on later. [00:44] RAOF: Sorry, gotta go ... life gets in the way sometimes. [00:48] StevenK: ok, upstream in several places typedefs Int32 to int and uses that to perform intense calculations like SHA1sums [00:49] StevenK: Heh I'll test kt more extensively on 64-bit but I wouldn't be surprised if its performance is much worse than on 32-bit [00:50] jdong: Yay [00:50] Isn't a short int 32 bits on 64 bit arches? [00:51] StevenK: I'm not too familiar with x86-64 [00:51] StevenK: but I'm suspecting an int to not be 32-bits [00:52] steven@liquified:~% ./size [00:52] sizeof(int) = 4 [00:52] sizeof(short int) = 2 [00:52] So it is. [00:52] Yup [00:53] hmm so int is 32-bits on x86-64? [00:54] Assuming sizeof(char) = 8 bytes, yes. [00:54] (A perfectly reasonable assumption, but not officially standard). [00:54] thanks [00:55] is long 64 in lm and 32 in regular? [00:55] RAOF: 8 bytes?! 8 bits, maybe? [00:55] StevenK: he uses galactic unicode :D [00:55] Muaha [00:55] jdong: Yes, long int is full word size [00:55] * RAOF is on x86-512 :P [00:55] lurn sumthin new every day :) [00:56] jdong: long int is 8 bytes [00:56] StevenK: Even for ia32? I've seen long int pointers work in ia32... [00:56] /me wonders why people don't use the standard int types. [00:56] persia: This is on amd64 [00:57] StevenK: Right. "long int" = 1 word (32/64/128/256) [00:59] sizeof(long int) == sizeof(int) on ia32 [00:59] (So, as persia says :-) [00:59] Actually, I've never tested that on a 256-bit machine. Long int might only be 128 bits there [01:00] Which machine has a word size of 128 bits? [01:00] Aside from RAOF imaginary one. [01:00] StevenK: A few in the HPC zone. NEC has a couple, crusoe used to be one. Nothing standard. [01:00] Ah. Nothing 'regular people' can get their hands on [01:01] * persia notes really old Honnywells used to have a word size of 60 bits [01:01] StevenK: crusoes were in consumer devices for a couple years, untili transmeta got out of the HW business. NEC stuff is trickier to get. [01:03] Why would crusoes have a word size of 128 bit, though? [01:04] StevenK: It's a VLIW chip that runs ia32 in software emulation. I don't know why they chose 128 bits, but apparently it almost worked for them. [01:05] Oh, that's right. I forgot Crusoes were really special [01:05] They just didn't quite have the money to go after the market they really were suited for, which was high-performance stuff IIRC. [01:06] Actually, I really liked them for low-power stuff, but everyone was focused on HMDs, which are just clunky. Now that we have small 200DPI screens, the handhelds are interesting again (and there are no crusoes) [01:07] to ensure available space for both their transness and their metaness === `23meg is now known as mgunes === SD-Plissken is now known as SD-Plissken`away [01:30] Heya gang [01:31] Hawdy bddebian [01:31] Hi RAOF [01:42] persia: I saw you set the gaphor won't start bug to triaged and unassigned yourself. Does it still not start? [01:43] * ScottK2 tries it. [01:43] ScottK2: It still doesn't start. Last I looked (~6 weeks back), upstream was releasing about once a week, and I couldn't get the snapshots available working. I'm planning to try again in the future, but don't want to block anyone else's effort if they are motivated. [01:44] More critically, the problem is well understood: it just needs some work: I don't think "new" is correct. [01:45] Cédric was working on gaphas a bit more since I looked last, and I'm planning on pushing a 10x or 11x into the repos for hardy even it doesn't work, as the current version is just too old. [01:46] persia: I have a new game for ya to debug for me ;-P [01:46] persia: OK. Makes sense. [01:46] bddebian: Which one this time (and do I get to forget conquest and scorched3d) ? :) [01:47] SilverTree. New package [01:47] And of course not ;-P [01:47] ScottK2: Most of the Ubuntu changes are in Debian, so we should be able to sync, although I won't want to wait for Debian after DIF. [01:48] bddebian: OK. What does it need? (I am blind at this time of day) [01:48] To work :-) I finally got it building but now I get an error about an empty wml file on startup [01:49] bddebian: What is a wml file? Some internal xml? [01:49] Seems so. === protonchris_ is now known as protonchris [01:50] Does it give a filename for the missing file, or just say "Can't load WML" or something similarly unhelpful? [01:50] Pretty much that unhelpful :-) [01:50] wml parse error: 'empty wml file' [01:51] persia: Does it still not work if built for python2.4? [01:52] ScottK2: 9.4 or so works fine with python2.4, but it doesn't use gaphas, which is the current model. 9.x is also not supported upstream. 8.x doesn't work with modern python-gtk. [01:52] bddebian: Yep: there's no scenarios in the upstream SVN. Write a plot :0 [01:52] persia: What about the 10.4 we have in the repos? [01:52] * persia looks [01:53] Oh, scenarios, wtf [01:53] Since it depends on Zope and Zope only works with 2.4 (IIRC), I think any hope of getting with working wtih 2.5 is forlorn at this point. [01:54] * ScottK2 needs to go put kids to bed. See you later. [01:54] ScottK2: Right. I forgot about that. That doesn't work either: it has a zope problem, and uses gaphas 0.2.x (I just asked for the gaphas 0.3.x sync recently, so it needs a bump, if nothing else). [01:54] persia: ^^^ [01:54] OK [01:55] Well I'd stick with Python 2.4 until Zope gets fixed for 2.5 (don't hold your breath). [01:55] ScottK2: It doesn't need to depend on zope, but that's a different issue. I'm putting it off until DIF, and will examine it again then. [01:55] Ah. OK. [01:55] See later. [01:55] .. you .. [01:55] Later ScottK [01:57] * jdong eyes persia for suggesting backporting iscsitarget O_o [01:57] looks like a hairy package to touch [02:00] jdong: Erm. Read that again: I remember saying "Don't do that - it's stupid. Also, fix gutsy now, and then do something else", but in a polite way. [02:00] persia: yeah, upon close read I detected "not gonna happen" [02:00] I'll comment on the bug too [02:01] jdong: You've already rejected the backports task: let's keep it trim for the SRU. [02:01] persia: Where do you see that there are no scenarios? [02:01] persia: ok, agreed [02:01] bddebian: I can't find any? (only looking with svn web gateway for a few minutes). [02:02] bddebian: I suspect they'll be packaged alongside, as with wesnoth, and so might be hidden somewhere. [02:02] I'll be damned if I can find them [02:03] bddebian: Right. didn't Baby say something about upstream not being ready yet? Did that get sorted? [02:04] Well according to the site and Forum it's supposed to be playable [02:04] Of course the upstream tarball is b0rked [02:04] bddebian: Hmmm. The wiki has some guidelines and examples for wml files, and apparently it's format compatible with wesnoth. I wonder... [02:05] persia: yeah, it's the same devs as Battle for Wesnoth [02:06] * StevenK kicks autoconf [02:07] * bddebian kicks StevenK [02:07] * persia watches two more versions climb out of the hedges... [02:07] ? [02:07] bddebian: So you're an old, buggy evil shell script? [02:08] Although, persia has a point. [02:08] Well I'm old and American so some might call me evil [02:09] * persia thinks bddebian is sufficiently unpredictable to be hard to write in shell: likely requires something more expressive. [02:09] brainfuck? :) [02:09] I can replace bddebian with a shell script [02:09] #!/bin/sh [02:09] echo "Complain about $SOMETHING" [02:10] exit 0 [02:10] hahahahaha [02:10] * StevenK ducks [02:10] You got me there [02:10] StevenK: The art is defining $SOMETHING, and having the alioth and REVU plugins [02:11] Okay, so I add a second line, ". /lib/persia/bddebian-funcs" [02:12] Right. I can't implement that in /bin/sh, but that's mostly a matter of not knowing higher curl syntax. [02:12] persia: Dare I say ruby? :-) [02:13] Probably could do it in Ruby: I don't know the http client syntax there either, but the interface is cleaner than pulling curl output into buffers in shell. [02:14] Actually I think StevenK nailed me in one line :-( [02:14] * persia defers to the voice of experience [02:15] Hmm, maybe this sucker just isnt ready for prime time [02:16] bddebian: If you're feeling especially motivated you could ping them, but I doubt they'll get it clean enough in the next month. Let's check again in mid-Jan: perhaps it'll be easier then (and we should still have time to get a sync in before FF). [02:17] persia: I already pinged the guy about the shitty tarball release ;-) [02:17] bddebian: Right. That works then. Maybe we'll get it sooner :) [02:29] Dear Anonymous Upstream Author: [02:29] Curse and screw you, with all respect, for packaging your sources as a tarbomb. [02:29] Love, jdong. [02:30] * jdong goes purge like 200 new files from his /tmp [02:31] * persia wants a tar switch which applies dpkg-style mangling to the extraction location automagically based on the tarfile name [02:32] persia: yes, or at least a "bomb defuser" switch to tar that refuses to extract when more than one entry is in the top-level-directory [02:33] jdong: I was reading the docs recently, and -C might help, but I can't figure out how to get it to extract so that one level up from $(CWD) is guaranteed to be the start of the branching tree. [02:33] persia: -C sets a new root directory to extract into, same as navigating PWD to one level higher [02:34] jdong: Still, gives some bomb protection :) [02:34] persia: I think I might hack up something for myself that just parses a tar -t type output to perform that sanity check [02:34] jdong: Pass me the wrapper if you get one that's reasonably robust. [02:36] jdong: Forward that to silvertree too will ya? ;-P [02:36] haha [02:36] you were bitten too? [02:38] persia: I'm thinking of something like "bombsquad tar xzvf foobar.tar.gz", (1) create new dir with temporary name (2) extract to that dir (3) Check # of 1st level entries, if more than one rename tempdir to tarball_name, if one then move that entry into ../ [02:39] persia: should be reasonably robust [02:40] * Hobbsee waves [02:40] jdong: Maybe: my worry in that case would be user error or assignment of tmp directories (/tmp may be on a different filesystem). Take a look at dpkg - it's really smart about it, and can handle lots of different formats if asked nicely. [02:41] hmm I'll have to look into that [02:42] Heya Hobbsee. [02:42] jdong: Also, dpkg gets hit with 15,000 different kinds of wrapped tarballs, from every imaginable source: even if you do go with bombsquad, it might contain some pointers for corner cases. [02:43] persia: yeah, I'll have to look into some of its heuristics [02:56] we darn it, my printer still doesn't work [02:56] *well [02:57] I wonder if an update killed it somehow [03:01] Dear deluge. Please *release* the libtorrent you're based on, so I don't have to watch g++ grind through boost's mega [03:01] -templates [03:02] RAOF: Don't they use a specific alternate libtorrent? I thought I saw something about some other software using the same variant in the last couple days. [03:02] persia: yeah, we talked yesterday about that [03:02] Yeah, there are apparently 2 libtorrents. [03:02] they use libTorrent, while rtorrent uses Libtorrent [03:02] However, I *think* the libtorrent in universe is the one they use. [03:03] Except that they don't. [03:03] Alternatively, they could stop using boost/templates/c++. That would also cut down the build time :) [03:04] RAOF: alternatively, transmission could just Replaces: deluge-torrent and we'd be done. [03:04] :D [03:04] * StevenK is pondering trying transmission [03:05] * RAOF aptitudes... [03:05] StevenK: whole heartedly recommend it [03:05] 0.93 is even better [03:05] 0.91 is okay if you are not using a router [03:06] jdong: But everyone uses a router (unless they're just torrenting around the flat) [03:06] jdong: Does it suck less than ktorrent? :-) [03:06] persia: meh I just plug a switch into my wall. I don't see why y'all need these NAT things. ;-) [03:07] StevenK: I'm supposed to be unbiased and love and feed all the torrent clients ;-) [03:07] jdong: Ah. NAT != router, but I now understand. [03:07] persia: pfft mr. technical. I can play that game too [03:07] *finds his compiz bug report* [03:07] persia: Exactly, NAT and routing are very different. [03:08] jdong: Then get Transmission 0.93 into Hardy [03:08] (And then backport it) [03:08] StevenK: http://jdong.mit.edu/~jdong/motu/transmission_0.93.dfsg-1.dsc <--- authentic jdong crack ready for Debian :) [03:08] StevenK: silly you for not suspecting jdong has fresh crack for everything ;-) [03:08] jdong: Do you need a sponsor for that? What's left? [03:09] StevenK: I don't know how transmission manages themselves in Debian. I think they have a VCS... dunno who to contact [03:09] I'm pretty sure just uploading that will piss off the maintainers [03:09] Right [03:09] What else is new? :-) [03:09] http://packages.qa.debian.org/t/transmission.html says they use collab-maint SVN. [03:09] bug 155666 [03:10] Launchpad bug 155666 in compiz ""Desktop Cube" is geometrically inaccurate" [Undecided,Invalid] https://launchpad.net/bugs/155666 [03:10] *grin* [03:10] So there is actually good chance you can just upload it (through correct procedures, of course). [03:10] jdong: The Maintainer is Philipp Benner, you could mail him [03:10] jdong: Can you do an avant-window-navigator backport as soon as it gets in hardy? :) [03:11] Amaranth: I'd love to [03:11] jdong: I need one less reason for people to use broken crap from trevinho's repo [03:11] jdong: That's a good bug, but upstream. You've complained there as well? [03:11] * StevenK cackles at jdong's compiz bug [03:11] persia: haha , nah, a few grins is enough ;-) [03:11] StevenK: I'll poke him [03:12] jdong: No, you've a valid point: it's worth following up: miseducation rarely is properly disabused. [03:12] hehe [03:12] if you're serious then I guess I could pursue it upstream :) [03:12] much to Amaranth's disbelief :) [03:12] persia: Actually I think silvertree might actually "work" [03:13] bddebian: Do you just stuff it with the base WML from the wiki? [03:13] Gah kids, bbiam [03:14] persia: Would you consider 'find $(CURIDR) -name 'Makefile' | xargs $(RM)' as makey enough? [03:14] * StevenK adds -print0 [03:15] * persia doesn't understand why nobody seems to like "-exec $(RM) {} +". It does the same thing in less memory. [03:15] * minghua wonders what are the translations for compiz's "cube"... [03:15] persia: people like one tool per job, and xargs is familiar, I guess [03:16] StevenK: No: it's shell. On the other hand, it's nearly a nice clean one-line shell call, and not worth complaining about. There's a make function that generates that list, so you can do $(RM) $(function args) which is even cleaner, but I'd have to test the syntax. [03:16] persia: Ah, but xargs will bundle up arguments, -exec {} \; doesn't [03:16] minimizing forking vs memory consumption... which is more important... [03:17] jdong: Perhaps. I think it's also that "-exec {} +" has only been around for a few years, and most people are still trying to avoid "-exec {} ;" which is ugly. [03:17] Hum. Bugger. [03:17] I need it to ignore ./Makefile, but delete every other [03:17] * minghua doesn't know about "-exec {} +". [03:17] I think StevenK needs to monitor free memory and forking speed in realtime and decide which one to use on the fly :) [03:17] *hides* [03:17] jdong: That's the "-exec {} ;" vs. xargs argument. "-exec {} +" wins, by being the best of both. [03:17] persia: what's the difference between + and ;? [03:18] persia: does + string the arguments together? [03:18] jdong: + acts like xargs, inside find. ; iterates. [03:18] persia: I only know '-exec {} \;' is it '-exec {} \+' ? [03:18] persia: fascinating. Why didn't I get the memo on this sooner? :) [03:18] * persia wanders away, suggesting man pages. [03:18] StevenK: Yes. [03:18] persia: Danke, I shall use that [03:20] * minghua blames find(1) man page for putting "-exec {} ;" above "-exec {} +". :-P [03:21] OH! -execdir! [03:22] * jdong looks at violating xserver-xgl's sanctity. [03:24] oh wait. [03:24] ## 01-compalloc-faster.dpatch by John Dong [03:24] looks like I already did it earlier [03:24] when did I do that? :D [03:24] Muahaha [03:25] look at me thinking one step ahead of myself. [03:25] just unfortunate it's my past self from 2 release cycles ago doing the foresight. [03:25] jdong: *Ages* ago. You were touching xgl well before me :) [03:26] For Feisty, IIRC. [03:26] -- John Dong Tue, 13 Mar 2007 10:35:24 -0400 [03:26] yeah, while back [03:27] * jdong wonders what to violate next.... [03:28] * LaserJock backs away slowly [03:28] jdong: There's your answer. Violate LaserJock until he posts Ponies! [03:29] LaserJock: oh yeah speaking of d and f orbital hybridization.... [03:29] (haha kidding. I'll do it myself this time :D) [03:29] jdong: phew, I thought you were going to start asking about HOMOs and LUMOs [03:30] LaserJock: fortunately this assignment is due on Wed, so disappear come 24 hours from now :) [03:30] np [03:31] * jdong goes stare at that avidemux package on REVU [03:32] -- Matvey Kozhev Sat, 17 Nov 2007 10:49:54 +0600 [03:32] LucidFox... sounds very familiar [03:32] I'll assume he's workin hard on it [03:34] * RAOF crosses deluge-torrent off his todo list. [03:37] RAOF: ooh shiny new deluge crack? [03:42] @#$$%^ stupid piece of shit [03:42] ok, the PPA documentation is not very explicit.... [03:42] jdong: Shiny new deluge *sync* [03:42] so what distros can I target via PPA? [03:42] * jdong wants to move backports testing onto PPA [03:42] jdong: anything supported. [03:43] is there any way to associate a bug to an upload to track build status? [03:43] without closing it, a la LP: #foo? [03:44] and thirdly, can PPA packages be removed? [03:45] Not really [03:47] * jdong tries a PPA "backport" for fun and games :) [03:47] jdong: You need to file an Answers request and then wait, if I recall [03:47] StevenK: heh well if it's a pain for them to do it on their end, I'd rather not make it a regular part of the process [03:50] do I always have to use -sa for the .changes or will it pick from even Hardy orig.tar.gz's for an upload at Gutsy? [03:50] jdong: You mean to PPA? [03:51] right [03:51] It won't pick up anything from the standard archives. I've never tried to target the same source at two targets though. [03:52] you need to name them differently. it wont work. [03:52] ok, I'll try with -sa and see what happens [03:52] whoo, note how my CPU And hard drive don't suffer for testing anymore :D [03:53] but it will spam ~ubuntu-backports-testers :D [03:53] poor saps. [03:54] good time to hack together some automated diffing/analysis tools for Backports too [03:56] persia: Sorry, back you still around? [03:57] bddebian: No, but just back. [03:58] So, the piece of shit has hardcoded relative paths. scenario.cfg does things like terrain='data/terrain.cfg' [03:58] But the damn thing still core dumps on me [03:59] bddebian: Got a stack trace? [03:59] No :) [03:59] Is it one of those bugs that only happens when you don't run GDB? [04:00] * persia solicits input on nifty ways to extract stacktraces from coredumps [04:01] TheMuso: Looking at it later, the old code ought to work for epochs (I'll try a test later), as the only thing it gets from the changelog is the revision, and the epoch applies to the version. [04:03] Man, I just suck [04:13] * LaserJock is embarassed to find the reason why his printer wasn't work for a few days [04:13] Unplugged? :) [04:14] almost [04:14] two black USB plugins [04:14] The cord was plugged in, but not making contact? [04:14] 1 for mouse, 1 for printer [04:14] printer went into the KVM :/ [04:14] Muahaha [04:14] heh [04:15] I'm sure the KVM had lots of stuff to print out [04:15] but since I plugged the mouse into the computer thinking it was the printer it worked [04:15] heh [04:15] zomg python must die [04:15] i broke it again [04:16] Just because you can't program in something doesn't mean it needs to die. [04:16] imbrandon: Implement a request-response stateless system in Ada. After that, python will feel good again. [04:16] heh [04:17] Does anyone know what happened to the vague murmurings of syncing into the archive from PPAs? Is that considered a bug that it doesn't work? A feature because such syncs should never happen? [04:18] er....i think that they might be able to do it now. [04:18] unsure. [04:18] the bug was solved, or almost solved. [04:18] Hobbsee: So it's considered a bug if it doesn't work? [04:19] persia: yea they SHOULD be able to sync from any apt repo, from what they told me [04:19] last time i asked [04:19] now if they choose to sync from particular repo is diffrent [04:19] persia: i think so. it also affects partner [04:20] Right. Sounds like there is a mix of a couple bugs an unclear policy. That's somewhat what I remembered, only in more detail. Thanks. [04:21] persia: you shouldnt expect better from soyuz :) [04:22] Hobbsee: I expect soyuz to work perfectly, do everything I want, give me all the information I find interesting, and have eight nines uptime. I may be disappointed once in a while, but if I expect less, it's just not fair to what it could be. [04:22] heh [04:22] well, this is true [04:23] Eight nines? What's that, 5 seconds per year downtime? [04:23] persia: in a few weeks, i'll probably be very interested to find otu what sort of info you'd find useful,e tc. === tritium_ is now known as tritium [04:23] StevenK: About that. I've only heard of two shops reaching nine nines, and that was expensive, (mostly about geodistributing redundant servers), so I can't expect everything :) [04:24] Hobbsee: My current wishlist is mostly in the QA list. I could make some more, but I'lll have to stick that lower in the queue. That timeframe sounds around right. [04:24] I would have thought anything past six nines would be acceptable [04:24] persia: mmm kay. i'll poke you about it in a few weeks [04:25] StevenK: Two 5 minute maintenance windows? If the app can do that, no reason not to rotate things out live and go for higher numbers, but sure. [04:28] persia: Ok. [04:58] anyone know a way to avoid the following error while taring up a dir tar: Error exit delayed from previous errors im using tar -cvzf tarball dir, it worked for nss but fails on nspr and ff3.0 [05:00] gnomefreak: That just means tar is stuck from something else, try without the "v", and see if the errors are more informative. [05:00] gnomefreak: have a look at what the previous errors were [05:00] also worked for xulrunner [05:00] Hobbsee: i didnt see them [05:01] wait maybe i did because i used tar -cvvf to start with but failed to build because it complained it wasnt a gzip tarball [05:02] tar: nspr-4.7.0~cvs20071106t1834/.pc/30_pkgconfig.patch/mozilla/nsprpub/config/nspr.pc.in: Cannot open: Permission denied [05:02] without v [05:02] maybe removing .pc dir will help? [05:03] gnomefreak: There you go. "v" is sometimes interesting, but it usually spews so much you can't tell what's going on. If you really want to look, I'd suggest only using "v" with "t". [05:03] or changing the permissions thereof. [05:03] should .pc be in top level dir? [05:05] ---------- 1 gnomefreak gnomefreak 0 Nov 19 20:02 nspr.pc.in [05:05] it has no permissions how does that happen? [05:06] nice file. [05:06] :-) [05:06] lol [05:06] i guess removing .pc will help than building with -S -sa will add it if needed [05:09] dear MOTUs, I'm looking for a second advocate for the ike package please. Thanks! ( http://revu.ubuntuwire.com/details.py?package=ike ) [05:21] LucidFox: ah thought that name was familiar, thanks for taking on the avidemux merge :) [05:22] LucidFox: one favor, I recently merged a new x264 into Hardy, can you version your libx264-dev build-dep (>= 1:0.svn20070930) so we make sure to build against that new version? [05:40] jdong> sure [05:43] keescook: Thanks for that rather large number of security uploads! [05:44] emgent: That gallery2/reupload diff you attached isn't particularly useful - the WebDAV CVEs also need to be fixed, and it includes a lot of extra changes. [05:52] jdong> uploaded [05:52] I can't test-build avidemux right now with the new x264, though, so I can't guarantee if the new upload will build [05:52] http://revu.tauware.de/details.py?package=avidemux [05:54] LucidFox: Is that a new upstream pull? If so would you mind knocking out the lintian messages? [05:55] persia> I knocked out all lintian messages I could find [05:56] the only one remaining is "no manpage for binary avidemux" in the transitional package avidemux, but it depends on avidemux-common, which provides the manpage [05:57] LucidFox: There are a couple more in the URL you just posted: outdated autotools hint files which can cause FTBFS, and broken releationships (which don't really matter in Ubuntu anyway). [05:57] Autotools aren't used [05:57] In 2.4, upstream provides a choice between autotools and CMake, and my packages use the latter [05:57] LucidFox: OK. Strange to see config.{sub,guess} if they aren't used. Nevermind. [05:58] Right. That explains it. Nevermind :) [06:04] LucidFox: if you are otherwise ready and not gonna make major packaging changes, I'd be glad to test locally whether they FTBFS or not for you :) [06:04] LucidFox: thanks for your work on avidemux :) [06:05] Why does the new x264 build-depend on GTK? [06:06]