[03:11] <Deist> Hi!
[03:11] <Deist> Sorry, in a bit of a mess with some c++ programing.
[03:12] <Deist> ah, sorry. wrong channel.
[03:12] <Deist> Hi!
[03:12] <Deist> Sorry, in a bit of a mess with a c++ programing code.
[03:12] <lucas> still wrong channel :-)
[03:13] <Deist> hah
[03:13] <Deist> what channel am i suppose to ask?
[03:14] <lucas> probably not this one. This one is for "Development of Ubuntu (not support, not app development)" (see the topic)
[03:14] <Deist> ah
[03:14] <Deist> closed the wrong cannel window :P
[06:59] <pitti> Good morning
[07:00] <ajmitch> morning pitti
[07:00] <pitti> hey ajmitch
[07:01] <bilalakhtar> good morning pitti
[07:53] <dholbach> good morning
[07:53] <bilalakhtar> dholbach: good morning
[07:54] <dholbach> hey bilalakhtar
[07:54] <bilalakhtar> dholbach: meeting's over
[07:54] <dholbach> bilalakhtar: I saw you're universe-contributor now - congratulations
[07:55] <bilalakhtar> dholbach: Thanks for your support and endorsement!
[07:55] <dholbach> :-)
[07:55] <dholbach> no worries
[08:21] <pitti> kees: did we actually enable the default umask change to 002 in maverick now?
[08:59] <dholbach> can somebody please review this? https://code.edge.launchpad.net/~marcelstimberg/ubuntu/lucid/gzip/gzip-fix-524366/+merge/27890
[08:59] <dholbach> MWelchUK_work_ can probably answer questions about it ^
[09:00] <MWelchUK_work_> Shame I missed the question :-)
[09:00] <MWelchUK_work_> !logs
[09:07] <pitti> MWelchUK_work_: can you please add the corresponding test case as well?
[09:07] <MWelchUK_work_> Sorry - I'm not the author of the patch, just a stuck user :-(
[09:08] <pitti> right, I know
[09:08] <MWelchUK_work_> (I can't migrate off of 8.04 until this is fixed)
[09:08] <pitti> the test case is in the upstream commit, too
[09:08] <pitti> MWelchUK_work_: oh, sorry, so you aren't Marcel Stimberg
[09:09] <MWelchUK_work_> Nope :-)
[09:09] <pitti> dholbach made it sound like you were the one proposing the merge
[09:09] <dholbach> I thought he was
[09:09] <MWelchUK_work_> Afraid not.
[09:21] <MWelchUK_work_> pitti, Thanks for the review.
[09:54] <ara> pitti, I uploaded a new version of mtdev that does not install the .la file. Can you please review and accept it in the binary archive?
[09:55] <pitti> ara: no, I can't
[09:55] <pitti> ara: I already did that yesterday :)
[09:55] <ara> pitti, ah, OK :-) thanks, then
[10:01] <tseliot> ara: you might want to ask cjwatson today, at least according to the wiki: https://wiki.ubuntu.com/ArchiveAdministration#Archive days
[11:26] <pitti> SpamapS: so, I now regularly get DB timeouts from work item tracker -- seems the charts/reports now take more than an hour to generate; wasn't the intention to limit per-user charts to some teams?
[11:26] <pitti> it now generates 1858 files every hour!
[11:27] <pitti> (per-user)
[11:41] <lifeless> pitti: DB timeouts ? LP ones or ???
[11:48] <pitti> lifeless: no, WI tracker sqlite db
[11:48] <pitti> i. e. next hour cronjob already kicks in while the previous one is still running
[11:48] <lifeless> ah heh
[11:50] <TheMuso> ouch
[14:06] <nigelb> Daviey: How complicated was setting up an etherpad instance for ubuntu-uk?
[14:07] <Daviey> nigelb, Pretty trival once the depends are satisfied
[14:07] <Daviey> .. There is now a apt repo
[14:08] <nigelb> Daviey: oh wow, apt-repo sounds really cool
[14:08] <Daviey> nigelb, I've not used it tho..
[14:08] <nigelb> Daviey: I'll try it out :) Thanks :)
[14:09] <Daviey> nigelb, Just be prepared to throw significant resources at it
[14:09] <nigelb> Daviey: ouch, how intensive is it?
[14:10] <nigelb> 512MB is okay or it eats more?
[14:12] <Daviey> Hmm.. that is pretty much the minimum - this server (oddly) has 818MB of RAM and etherpad is using 65%, and the whole system is marked at   711MB in use and 721MB in swap (but that is caching).
[14:19] <nigelb> Daviey: the server I'm going to run it on has 2 GB of ram, but then it has a jabber server and apache
[14:21] <Daviey> nigelb, I'm sure it will be ok.. give it a spin
[14:31] <highvoltage> http://packages.ubuntu.com/maverick/ <- anyone happen to know what the blocker is for getting that fixed?
[14:57] <geser> highvoltage: getting hold of someone with access, cjwatson might know the current status
[14:59] <pitti> jdstrand: do you have any idea about bug 606163? does this need a kernel log to actually see the violations?
[14:59] <pitti> jdstrand: (it's marked for alpha-3)
[14:59] <jdstrand> pitti: hey. reading
[14:59] <pitti> it clearly doesn't happen for everyone
[15:00] <pitti> otherwise hell would have broken loose a long time ago
[15:00] <cjwatson> highvoltage: I filed a ticket with our sysadmins - it's awaiting a response
[15:00] <jdstrand> pitti: this is probably a dupe of bug #599450
[15:00] <pitti> or it did, and everyone who wanted to tell us was now offline :)
[15:00] <pitti> jdstrand: ah, thanks
[15:00] <jdstrand> pitti: so the reporter can retest
[15:01] <pitti> jdstrand: thanks! I'll follow up
[15:10] <jdstrand> sure thing
[15:11] <pitti> JontheEchidna: hello, how are you?
[15:12] <JontheEchidna> pitti: pretty good
[15:12] <pitti> JontheEchidna: bug 600606 says that you have a fix for the FTBFS?
[15:12] <pitti> JontheEchidna: that bug is marked for alpha-3; I'm fine moving it, but I wondered if it could just be done now, to get it off the list
[15:12] <JontheEchidna> pitti: yes, it's been committed to bzr, but other changes in bzr are waiting on an MIR for a new runtime dependency
[15:13] <pitti> JontheEchidna: ah, ok; it's not an alpha-3 blocker, so is it ok if I move the bug to beta?
[15:13] <JontheEchidna> pitti: sure. as long as it gets fixed by release it shouldn't block anything
[15:14] <pitti> JontheEchidna: ok, thank you
[15:27] <pitti> ogra: do you have a gut feeling whether bug 605488  and bug 605739 are serious enough to block alpha-3 on armel? or should we just move to beta?
[15:27] <ogra> just move them
[15:27] <pitti> 605739  seems to have an upstream patch, but 605488 doesn't show any progress
[15:27] <pitti> ogra: ok
[15:27] <ogra> we dropped swap for the moment
[15:28] <pitti> ah, so workaround
[15:28] <ogra> i will only enable the sawpfile/partition creation once the kernel is fixed
[15:28] <pitti> ogra: and for 605488 it seems that it doesn't actually halt the system, you just get this in dmeg?
[15:28] <pitti> dmesg
[15:29] <ogra> thats the MMC issue i mentioned before
[15:29] <ogra> we wont get any fixes for either bug in, so just move them
[15:31] <pitti> ogra: well, if it completely breaks boot, then we don't need to release alpha-3/armel at this point; we could release images later on when we have a fix
[15:31] <pitti> it doesn't sound like it would break boot, but I wanted to confirm
[15:31] <ogra> it breaks booting on certain HW, not on all
[15:32] <ogra> but waiting for a kernel fix would take us days
[15:32] <pitti> release note then?
[15:32] <ogra> the archive would be out of sync agaion etc etc
[15:32] <ogra> yeah, we definately need something like "doesnt boot on XM boards"
[15:33] <ogra> though given the board isnt sold yet i dont think its important anyway :)
[15:33] <pitti> ogra: ah, you already know those? please feel free to add to https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview#Known%20issues, otherwise I'll invent something
[15:33] <pitti> ogra: ah, that'd help :)
[15:33] <ogra> heh
[15:34] <ogra> only the beagle C4 is available and that doesnt really meet the minimal HW reqs for netbook
[15:34] <ogra> the actual arches we work for are all non existing :)
[15:37] <pitti> JontheEchidna, Riddell: is bug 586497  already fixed in maverick? it was SRUed, but it didn't say that it was backported from maverick
[15:39] <Riddell> hmm, checking
[15:39] <JontheEchidna> looks like it was fixed in maverick too
[15:39] <pitti> \o/
[15:39] <JontheEchidna> http://launchpadlibrarian.net/50536327/kpackagekit_0.5.4-0ubuntu5_0.6.0-0ubuntu1.diff.gz
[15:40] <JontheEchidna> +++ kpackagekit-0.6.0/debian/patches/kubuntu_06_no_automatic_updates.diff
[15:41] <pitti> JontheEchidna: thanks
[15:41] <Riddell> yes, although it doesn't seem to be in the changelog, that's strange
[15:42] <pitti> ok, that makes https://bugs.edge.launchpad.net/ubuntu/maverick/+bugs?field.searchtext=&orderby=status&field.milestone%3Alist=27561 look much better now
[15:43] <pitti> and I guess the ureadahead armel OOM is something for release notes
[15:46]  * pitti comments on the bug
[16:07] <dholbach> can somebody have a look at the ACKed syncs?
[16:11] <seb128> dholbach, can do
[16:12]  * dholbach hugs seb128
[16:12]  * seb128 hugs dholbach back
[16:12] <dholbach> seb128: Jono had a mumble problem and I saw there was a sync open for it
[17:17] <kees> pitti: I wasn't involved in the umask change, no.
[17:27] <mathiaz> jjohansen: hi!
[17:27] <jjohansen> mathiaz: hey
[17:27] <mathiaz> jjohansen: it seems that the linux-virtual kernel now returns linux-virtual from uname -r
[17:28] <mathiaz> jjohansen: http://paste.ubuntu.com/473154/
[17:28] <mathiaz> jjohansen: is this something new in maverick?
[17:30] <jjohansen> hrmm, yes
[17:30] <jjohansen> virtual became a true flavor
[17:30] <jjohansen> previously, -virtual was a subflavor of -server
[17:31] <jjohansen> so it got the -server name appended, but with it being a true flavor it now gets -virtual
[17:31] <mathiaz> jjohansen: -server on amd64 and -pae on i386
[17:31] <mathiaz> jjohansen: starting from maverick -virtual on both amd64 and i386?
[17:31] <jjohansen> mathiaz: right, so now it should be -virtual on both
[17:31] <jjohansen> yep
[17:31] <mathiaz> jjohansen: great - thanks for the help
[18:09] <pitti> cjwatson: hm, usb-discover needs to be ported to discover-data (also in debian), discover1-data is NBS
[18:10] <pitti> cjwatson: are you already planning this, or want me to have a look?
[18:11] <pitti> it's the only remaining rdepends
[18:19] <pitti> ttx, ScottK: hm, what happened to dovecot-postfix? it's NBS in maverick, but I don't see a transition path?
[18:20] <pitti> oh, mail-stack-delivery, nevermind
[18:20] <pitti> but that didn't exist in lucid, so we need dovecot-postfix as a transitional package until the next LTS
[18:21] <pitti> so can you please reintroduce it?
[18:21] <pitti> zul: ^
[18:21] <zul> pitti: ack
[18:36] <ScottK> pitti: IIRC there was a transitional package when last I touched it.  Not sure how it got dropped.
[18:56] <shabbu> need help:  My pen drive is in write protection. How can i remove write protection in ubuntu 10.04?
[19:18] <Pretto> does anyone had this problem using anjuta on ubuntu 10.04?? Assertion 'pthread_setspecific(t->key, userdata) == 0' failed at pulsecore/thread-posix.c:196, function pa_tls_set(). Aborting.
[19:44] <slangasek> cjwatson, lool: should xdeb use launchpad for upstream bug tracking, or should bugs be filed directly against the Ubuntu package?
[19:48] <sbronsted> Question: How often is http://qa.ubuntuwire.org/ftbfs/ updated? I was look at httpcomponents-core but when I do pbuilder on the source there is no error
[20:07] <kiko> crimsun, hey there
[20:07] <kiko> have a second for a small bug?
[20:08] <Pici> Hes been idle for two days... so likely not.
[20:09] <pitti> ScottK: seems the last merge dropped it or so; seems zul's on it
[20:09] <ScottK> OK.
[20:18] <kiko> thanks Pici :-
[20:25]  * soren hugs seb128 for the python-lockfile sync
[20:25] <seb128> soren, ;-)
[20:42] <mr_pouit> seb128: thanks for the syncs. At last there's no delta with goffice in debian. ;)
[20:42] <seb128> yw ;-)
[20:42] <seb128> thanks for getting the change in debian
[20:45] <ari-tczew> cjwatson: could you merge package 'parted'? it's needed for build package
[20:45] <ari-tczew> 'pyparted'
[20:51] <maco> ugh, male enhancement spam on ubuntu-devel@l.u.c
[20:52] <soren> And now in #ubuntu-devel :)
[20:53] <micahg> thank you to whoever just ran through all the sync requests (thinking it Riddell)
[20:54] <micahg> no, I guess it was seb128 <-- thanks :)
[20:54] <geser> yeah, seb128 did them this time. thanks
[20:54] <seb128> yw ;-)
[21:06] <ScottK> Did we decide to skip the Alpha 3 freeze?
[21:06] <ScottK> Seems like lots of Main uploads today.
[21:06] <pitti> ScottK: no, I sent it yesterday
[21:07] <maco> soren: i didnt give the link :P
[21:07] <soren> maco: Don't worry, I googled for it. :)
[21:07] <maco> soren: oh thats what you want in your browser history :P
[21:11] <soren> maco: Hey, it's not my fault I'm highly suggestive.
[21:11] <soren> :)
[21:16] <highvoltage> being highly suggestive is my biggest weakness
[21:16] <highvoltage> (I guess I shouldn't say that publicly :) )
[21:18] <highvoltage> (and I actually meant "suggestable")
[21:29] <soren> Err.. Yeah, s/suggestive/suggestible/ for me, too.
[21:29] <soren> highvoltage: Good catch :)
[21:36] <highvoltage> well I can be quite suggestive too, seems like it works both ways :)
[21:44] <ScottK> cjwatson: Is there any intent to move to parted 2.3 in this cycle?  pyparted in Universe is currently depwait on >= 2.3, so if not, we'll need to do something with it.
[21:47] <ScottK> DktrKranz: ^^^ It appears to be your pyparted upload that's not building.
[21:47] <ari-tczew> ScottK: I endorsed the same 1 hour ago :)
[21:48] <ScottK> ari-tczew: I see that now.  I'd rather see what cjwatson plans for parted and then adjust pyparted accordingly.  Looks like it will need a patch added back if parted isn't updated.
[22:10] <ari-tczew> what about getting latest debhelper into ubuntu?
[22:19] <andreserl> anyone expert in Python available to give me a hand around?
[22:21] <RoAkSoAx> Anyone expert in Python and subprocess available to give me a hand around?
[22:22] <geser> why this high demand for Python experts right now?
[22:23] <micahg> geser: same person :)
[22:24] <RoAkSoAx> geser: yep same person, :)!
[22:25] <geser> RoAkSoAx: I'm no expert but perhaps I can still help. What's the problem?
[22:26] <RoAkSoAx> geser: ok. For TestDrive-gtk I want to display the rsync progress. However, rsync shows the progress in 1 single line, and to capture the progress I'm doing something like: http://pastebin.ubuntu.com/473259/
[22:28] <tumbleweed> RoAkSoAx: what's with the massive while loop?
[22:28] <tumbleweed> RoAkSoAx: cmd = command.split()
[22:28] <tumbleweed> ^ that probably does what you want
[22:28] <geser> I've the same question about this part
[22:29] <RoAkSoAx> tumbleweed: geser : the massive while loop just puts 'rsync -azP etc etc' into an array for subprocess
[22:32] <geser> RoAkSoAx: like tumbleweed said "cmd = command.split()" gives you an array and the doc for Popen says that a string it also ok
[22:32] <tumbleweed> geser: IIRC a string is only ok if you use shell=True
[22:32] <RoAkSoAx> anyways, thge thing is that rsync displays the output in the way of: http://pastebin.ubuntu.com/473270/ and keeps updating that 4th line with the progress. However, when I run the script it diusplays only the first 3 lines: http://pastebin.ubuntu.com/473273/, and displays the 4th when rsync is done. Some I'm wondering how to do to grab that 4th line update with the progress
[22:33] <tumbleweed> RoAkSoAx: rsync detects that it's not being run in a terminal, and doesn't output status
[22:33] <RoAkSoAx> tumbleweed: geser: Yes, an string is good when using shell=True, but I'm not using that
[22:33] <tumbleweed> RoAkSoAx: seriously, try simpler solution I gave you
[22:33] <tumbleweed> (this isn't C, it's python)
[22:33] <RoAkSoAx> tumbleweed: it outputs the status of the progress when rsync finishes syncing, or when for example, I kill the rsync process
[22:33] <tumbleweed> s/status/progress/
[22:34] <RoAkSoAx> tumbleweed: using shell=True?
[22:34] <tumbleweed> RoAkSoAx: no
[22:35] <RoAkSoAx> tumbleweed: then I think i missed your solution. What is it again?
[22:36] <RoAkSoAx> cmd = command.split()
[22:36] <RoAkSoAx> ?
[22:36] <RoAkSoAx> instead of the loop?
[22:36] <tumbleweed> RoAkSoAx: it's not a solution to your problem, i'm saying you can replace lines 4..12 with cmd = command.split()
[22:36] <RoAkSoAx> tumbleweed: oh yep, I'm gonna do that thanks :). However, no ideas for my problem?
[22:37] <geser> RoAkSoAx: why not write command as a list in the first place? "command = ['rsync', '-azP', ...]
[22:37] <tumbleweed> RoAkSoAx: there are python rsync modules, maybe one of them can help you
[22:38] <tumbleweed> but I don't see any easy way to persuade rsync to output progress
[22:41] <RoAkSoAx> geser: because the way how testdrive did it initially was tu run a command directly, however, in testdrice-cli it still uses it that way, but in the -gtk I need the array given that I'm running the sync in a subprocess + threads
[22:42] <RoAkSoAx> tumbleweed: ok I'll investigate that! Thanks :)
[22:44] <pitti> superm1: mythbuntu has failed to build for some days (see http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/mythbuntu/20100803/livecd-20100803-i386.out); are you interested at all in an alpha-3 release, or do you want to skip it?
[22:45] <RoAkSoAx> geser: and by directly I mean with os.system()
[22:46] <tumbleweed> RoAkSoAx: to see what I mean, try this: rsync -azP foo bar | cat
[22:48] <tumbleweed> err, I screwed up, RoAkSoAx it will work
[22:49] <tumbleweed> RoAkSoAx: just look for \r to find the new line of output
[22:50] <RoAkSoAx> tumbleweed: that's the thing, the progress update is done in one single line, which makes my script to hang up when reading that exact line.
[22:53] <tumbleweed> RoAkSoAx: don't do readline(), read a handful of bytes at a time, and you know you've got a new line when you see \r
[22:56] <RoAkSoAx> tumbleweed: ok. btw I;'ve just found same issue here with no solution yet: http://stackoverflow.com/questions/1606795/catching-stdout-in-realtime-from-subprocess
[23:07] <tumbleweed> RoAkSoAx: http://paste.debian.net/82254/ all that's left is parsing the output with a regex (but I'd still see if there's a nice python library that make sthis easy)
[23:11] <RoAkSoAx> tumbleweed: awesome!! thanks a lot :)
[23:12] <tumbleweed> RoAkSoAx: assuming the output is always 43 chars, long, you can self-synchronise: buff += sync.stdout.read(min(16, 43 - len(buff)))
[23:14] <RoAkSoAx> tumbleweed: :) thanks for the tips :)
[23:15] <tumbleweed> RoAkSoAx: be aware that you now have to kill the rsync if your program dies
[23:16] <tumbleweed> actually, no it should SIGPIPE
[23:17] <RoAkSoAx> tumbleweed: I'll see what happens when I do that in a thread though
[23:19] <SpamapS> wow.. seems like mdadm needs some bug fixing love https://bugs.launchpad.net/ubuntu/+source/mdadm
[23:50] <superm1> pitti, we were interested, just been a little behind in testing :)
[23:50] <superm1> i'll take a look right now
[23:55] <dupondje> do we plan to upgrade mdadm btw ?