[01:40] <directhex> asac, ping
[03:49] <achiang> ping humphreybc
[03:49] <achiang> argh fat fingers
[05:20] <sabgenton> cjwatson: is the website admin about?
[05:21] <sabgenton> I don't know his nick
[05:58] <cjwatson> sabgenton: no
[05:59] <sabgenton> yes I knowticed  I found his nick :)
[05:59] <sabgenton> newz2000
[06:01] <cjwatson> I don't like giving out personal contact info when there are plenty of advertised ways to contact webmaster which don't rely on it being that one person
[06:01] <cjwatson> (the ubuntu-website project in LP, webmaster@)
[06:02] <sabgenton> ?
[06:02] <sabgenton> LP
[06:03] <cjwatson> Launchpad
[06:03] <sabgenton> sorry
[06:06] <sabgenton> I have since found that to install ubuntu server with usb-creator is now possbile but not with The out of the box instructions given on the website
[06:09] <nigelb> sabgenton: why don't you open a bug against the ubuntu-website project?
[06:09] <nigelb> I'm sure the concerned folks will take a look at it when they come online :)
[06:12] <cjwatson> nigelb: I suggested that to sabgenton several days ago too
[06:12] <cjwatson> I don't think stalking the webmaster on IRC is a good way to get things done, generally
[06:16] <sabgenton> meah ok
[06:16] <sabgenton> I posted the bug
[06:17] <sabgenton> cjwatson: is the any proper way to bump a bug?
[06:19] <nigelb> sabgenton: you don't have to, they get a mail automatically
[06:19] <nigelb> cjwatson: agreed there
[06:20] <sabgenton> ok I'll just leave the bug
[07:01] <dholbach> good morning
[07:22] <pitti> Good morning
[07:23] <dholbach> hey pitti
[09:16] <asac> directhex: ?
[09:17] <lifeless> the 'share this network' stuff in NM is really pretty neat.
[09:17] <RAOF> NM is really pretty neat.
[09:17] <directhex> asac, i'm tracking down ARM problems with mono. it looks like our current 2.6.3-2 package in experimental, which includes the previous ubuntu ARM changes, doesn't build on the debian arm porterbox ("illegal instruction")
[09:17] <lifeless> RAOF: the adjective I had in mind was a tad different.
[09:18] <lifeless> I like this bit ;)
[09:18] <directhex> asac, getting ARM working well is a blocker on pulling it into maverick
[09:20] <asac> directhex: hmm
[09:21] <asac> directhex: i can see what happenes on our porter box
[09:21] <asac> give me the .dsc ;)
[09:21] <directhex> http://ftp.de.debian.org/debian/pool/main/m/mono/mono_2.6.3-2.dsc
[09:22] <directhex> on agricola, it fails about a third of the way through the build, i.e. when bootstrapping the class library, after building the C-based runtime
[09:27] <pitti> asac: I prepared the dpkg filtering patch for maverick, FYI; but didn't you say that there was a WI for that?
[09:29] <asac> pitti: one second. let me give you an item ;)
[09:29] <pitti> oh, I was just wondernig whether I should close something
[09:30] <asac> pitti: you said you also needed to upload apt?
[09:30] <pitti> do I?
[09:30] <pitti> asac: depends on what you want to do; these are quite independent
[09:30] <pitti> but I'd like mvo to have a look at my MP first before I put it into the official distro
[09:31] <asac> kk
[09:33] <asac> pitti: added that work item to arm-m-on-disk-footprint and set it to DONE for you. also added an apt item there
[09:33] <pitti> ok, thanks
[09:37] <Chipzz> sabgenton: and FWIW, "bumping" a bug is hardly ever an appropriate thing to do in my personal opinion
[09:38] <Chipzz> personally I find "bumping" a bug obnoxious behaviour
[09:39] <sabgenton> Chipzz: so if no one answers just leave it ?
[09:41] <Chipzz> sabgenton: they'll get to when they get to it
[09:42] <Chipzz> you don't know what else they have on their plate
[09:42] <Chipzz> that's the whole point of a bug tracking system
[09:42] <sabgenton> mm
[09:42] <directhex> 372 test(s) passed. 7 test(s) did not pass.
[09:43] <sabgenton> I'm just trying to understand the ettiquett
[09:43] <sabgenton> Chipzz: do all bugs get read eventually
[09:43] <Chipzz> yes
[09:43] <sabgenton> or do some get disgarded
[09:44] <asac> Riddell: please fix 512146
[09:44] <Chipzz> like cjwatson pointed out above, the person responsable will get an email about it
[09:44] <asac> that clearly had open MIR points when you promoted ;)
[09:44] <sabgenton> if It say there for like 9 months or something should I take action
[09:45] <sabgenton>  / raise awarness
[09:45] <jibel> mvo, chrisccoulson, hey, latest flashplugin-nonfree in lucid-proposed introduces a regression. Could you please have a look at 429841 again.
[09:45] <sabgenton> or does that not happen
[09:45] <asac> Riddell: same for 512148
[09:46] <sabgenton> (it was barrly yesterday :)  )
[09:46] <directhex> 7 fails is a HUGE improvement on what's in lucid
[09:47] <sabgenton> Chipzz: with the understanding of time u just gave me I will leave it at thatt :)
[09:47] <chrisccoulson> bug 429841
[09:47] <chrisccoulson> :)
[09:47] <Chipzz> sabgenton: raising awareness is sth which is often done
[09:47] <sabgenton> sth?
[09:48] <Chipzz> I disagree with the whole sentiment of "raising awareness", but that is again, my very personnal opinion
[09:48] <Chipzz> sth -> something
[09:48] <Riddell> asac: both opengtl and plotutils have .symbols files
[09:49] <sabgenton> Chipzz: do you believe someone should submit and then trust the system?
[09:49] <sabgenton> no matter the time
[09:50] <Chipzz> if say one year passes you may consider bumping it
[09:50] <asac> Riddell: right. but plotutils the warnings still left
[09:50] <asac> at least one "definitly fix"
[09:50] <Chipzz> but it's not like bugs get deleted from the BTS
[09:50] <Riddell> asac: right enough.  what's up with opengtl?
[09:50] <sabgenton> Chipzz: ok I think I agree with that
[09:51] <Chipzz> it may just not be a high priority for the person involved
[09:51] <mvo> thanks jibel, I check it out
[09:51] <asac> Riddell: now looking at the comments, its fine. thx
[09:51] <sabgenton> :)
[09:51] <asac> Riddell: so just plotutils ;)
[09:54] <asac> Riddell: also bug 512159 has still a few issues
[10:06] <seb128> hum, do we really need tk8.4 in the default installation?
[10:07] <seb128> it seems only recommended by some of the printing stack components right now
[10:13] <pitti> I'd like to get rid of it, indeed
[10:13] <pitti> we have had 8.5 in main for quite some time now
[10:14] <BlackZ> could someone look at bug #598874 ? this situation should be solved BTW
[10:16] <BlackZ> (libmpcdec is in main)
[10:24] <seb128> pitti, but do we need any tk at all on the default installation?
[10:25] <pitti> seb128: not sure what still needs it; would be nice to get rid of it, of course
[10:28] <directhex> purging it doesn't seem to remove anything else
[10:33] <hrw> cjwatson: can you link xdeb page there: https://edge.launchpad.net/ubuntu/+source/xdeb ?
[11:14] <cjwatson> hrw: urgh, cross-channel stuff, let's keep this on #linaro?
[11:15] <hrw> cjwatson: ok
[11:19] <vaul1> Hello people. Could someone please give me guidance? I want to know where to post a request for a mono icon for an application in Launchpad.
[11:24] <lifeless> what do you mean?
[11:25] <vaul1> I want designers of a standard Ubuntu icon theme to draw an icon for an application that I use.
[11:25] <lifeless> hmm
[11:25] <vaul1> And I want to know where on Launchpad to post a request about that.
[11:25] <lifeless> possibly the ubuntu artwork list
[11:25] <vaul1> Concearning?
[11:25] <lifeless> I'm not sure a bug is the best way to get the attention of artwork folk
[11:26] <vaul1> Bug, feature request — what is a better way to get an attention of some developer?
[11:29] <vaul1> There is a «Humanity» team, maybe it is a place?
[11:31] <vaul1> There are similar reports here, so I am opening a report.
[11:32] <vaul1> It seems there is not much life here, though.
[11:33] <vaul1> Oh, «ubuntu-mono» seems an exact match for that, in case anyone else is interested.
[12:00] <lamont> cjwatson: how would you feel about ltsp-server [i386] for a depends?
[12:02] <cjwatson> lamont: seems too heavyweight really.  we often advise people to install livecd-rootfs when they're doing customisation
[12:02] <lamont> cjwatson: ok.  I'll fix make-chroot.sh to install it then.
[12:23] <lamont> cjwatson: all fix0red. enjoy
[12:25] <cjwatson> thanks
[12:25] <cjwatson> I shall enjoy two fewer mails per day, hopefully
[12:26] <lamont> sounds like a drop in the bucket
[12:27] <lamont> cjwatson: on a different note, do you happen to remember which architecture was throwing random SIGILLs back when?  I'm thinking of dropping that auto-retry, since we've found at least one solid SIGILL on arm
[12:28] <cjwatson> I don't, sadly
[12:29] <lamont> I'm fairly certain it was either hppa or ppc, just can't remember for sure which
[12:29] <directhex> is there an ARM porterbox available to non-canonical staff?
[12:29] <lamont> not that I know of
[12:30] <directhex> how vexatious
[12:30] <siretart> asac: what's the problem with libva? it does provide a shlibs file: "libva 1 libva1"
[12:32] <asac> siretart: hmm. did i miss that?
[12:33] <asac> siretart: you do that manually?
[12:33] <siretart> asac: I've just downloaded the .deb from launchpad and checked with 'dpkg-deb -I libva1_1.0.1-3_i386.deb shlibs'
[12:33] <asac> siretart: thats the auto generated file, yes. having that maintained explicitly in rules gives more confidence
[12:33] <asac> that someone is actually caring about that ;)
[12:34] <siretart> asac: which is perfectly fine until upstream actually does a change that is not.
[12:34] <siretart> asac: so you require some special action from the maintainer to indicate "I promise that I will check on the next upload?"
[12:34] <siretart> sorry?
[12:34] <asac> siretart: actually i want .symbols files
[12:35] <asac> so i dont need to hope that debian maintainer knows how to do that and does it right
[12:35] <siretart> asac: uff? is that a new ubuntu policy? since when do all libraries in main need to have .symbols files?
[12:35] <asac> siretart: as i said. i want .symbols files
[12:35] <asac> but its not required. i just want confidence that abi is properly tracked
[12:36] <seb128> siretart, hey
[12:36] <asac> having no explicit makeshlibs doesnt give that to me
[12:36] <siretart> hi seb128
[12:36] <seb128> siretart, did you talk with sirestart about ffmpeg 49 and 50 binaries overwritting files issues?
[12:36] <seb128> ups
[12:36] <siretart> asac: in the pkg-multimedia team, we do maintain quite some libraries and we do care about ABI/API issues
[12:36] <asac> siretart has two owners now?
[12:36] <asac> siretart: how do you track them?
[12:37] <seb128> siretart, with Sarvatt I meant
[12:37] <siretart> with objdump?
[12:37] <siretart> seb128: no, he didn't contact me. what's the lp bug number you're talking about?
[12:37] <asac> siretart: so you double check for every upstream pick that nothing changed and do the right thing?
[12:37] <siretart> I do, yes.
[12:37] <seb128> siretart,
[12:37] <seb128> juin 25 00:36:58 <Sarvatt>	gstreamer0.10-ffmpeg should just be built against libavutil50 anyway though shouldn't it?
[12:37] <seb128> juin 25 00:38:17 <Sarvatt>	other junk is still using libavutil49 though like vlc and thats screwed up also if you have extra installed :(
[12:37] <seb128> juin 25 00:40:02 <Sarvatt>	yeah libavutil49 isn't even built in ffmpeg-extra anymore so the screwed up empty package is just hanging around in the archive
[12:38] <asac> siretart: you do ... but how about the others ;) ... what i think is that its hard to see that a team i dont know cares about this in a way that we can rely on it here
[12:38] <siretart> asac: if there is a rule that all libs in main are required to have .symbols file, please show it to me
[12:38] <asac> but i can approve it if you say its not going to be a problem ;)
[12:38] <asac> siretart: as i said. there is no rule. and i didnt ask for that
[12:39] <siretart> you said something else at 13:35
[12:39] <asac> 13:35 < asac> siretart: as i said. i want .symbols files
[12:39] <asac> 13:36 < asac> but its not required. i just want confidence that abi is properly tracked
[12:39] <asac> no ... thats what i said ;)
[12:39] <siretart> I see
[12:39] <siretart> seb128: he seems pretty confused
[12:40] <asac> the easiest way to convince is .symbols ... not sure why thats a problem for anyone doing lib maintenance though
[12:40] <siretart> seb128: libavutil49 is NBS, packages will drop that dependency as they are rebuilt
[12:40] <seb128> siretart, dunno, but we got quite some bugs about avi playing not working in maverick, not sure if that's because we still use the wrong one
[12:40] <seb128> siretart, well, then we need to rebuild things to pick the new soname?
[12:41] <siretart> seb128: having libavutil49 and libavutil50 loaded at the same time shouldn't be a problem anymore, as I've introduced symbol versioning upstream
[12:41] <siretart> seb128: if there is an undeclared file conflict, please file a bug and tell me the bug number. I'll take care of that
[12:41] <siretart> if there is a crash, I'd need a backtrace
[12:41] <seb128> juin 25 00:33:24 <Sarvatt>	libavutil49 is correct, its libavutil-extra-49 that is screwed up and that replaces libavutil49
[12:41] <seb128> siretart, I will check what's going on
[12:41] <seb128> siretart, I think he said he managed to get files overwritten and then not there after an upgrade
[12:41] <siretart> of course libavutil-extra-49 is supposed to replace libavutil49. same for the 50 variant
[12:42] <siretart> we are doing that game for a couple of releases
[12:42] <siretart> is he on amd64?
[12:42] <siretart> the amd64 build arrived only this weekend, because of the vdpau trouble
[12:42] <seb128> could be
[12:42] <siretart> that I fixed this weekend by disabling the 32bit libs
[12:42] <seb128> siretart, I was just checking if you knew anything before spending time on that
[12:43] <seb128> siretart, I will try to figure what the issues are now and ping you back later if needed, thanks
[12:43] <siretart> seb128: as said, I'm not aware of a problem related to that
[12:43] <siretart> ok
[12:44] <siretart> asac: .symbol files are still a huge pain for c++ libraries. We've tried for libjack, but it's pretty pointless there
[12:44] <asac> siretart: we have a lot of crack libs in main even. some have loads of symbols exported that should never have been exported (e.g. _xxx symbols that were not properly hidden upstream). i just want to ensure that folks get reminded about this topic whenever upstream changes their abi/api and .symbols is the easiest way i can currently see that will ensure that such a reminder will take place
[12:44] <siretart> IIRC libva is plain c, so adding .symbol files should be rather easy
[12:44] <asac> siretart: yeah i see your point
[12:44] <asac> but libva is C ;)
[12:44] <siretart> as said
[12:44] <asac> yep
[12:45] <siretart> btw, for ffmpeg, these libs also don't provide .symbols files, and won't in the forseable future
[12:45] <asac> in the end i trust you to do the right thing. but in general i am looking at a package without knowing its origin etc.
[12:45] <siretart> I play rather dirty tricks with the shlibs file so that the ffmpeg-extra trick works
[12:45] <asac> sad enough ;)
[12:45] <siretart> or other way round, I cannot implement that trick with symbol files
[12:45] <siretart> oh, I'd also love to get rid of that trick
[12:46] <siretart> but that would require to promote liblame, x264 and xvidcore to main
[12:46] <siretart> would you be more comfortable with that? ;-)
[12:46] <asac> but does that mean that all other libs shouldnt use symbols ;)?
[12:46] <asac> siretart: i didnt talk about ffmpeg here
[12:47] <asac> anyway. you can choosed: a) add .symbols \o/ ... b) add explicit makeshlibs o/ c) keep it as is and state the process you have in place in the multimedia team that will ensure that abi/api will be properly tracked
[12:47] <asac> all three are good enough to get approval
[12:47] <siretart> no, I just wanted to point out that I do care about ABI/API issues, and that I feel your decision to make a .symbol file a requirement for libva's promotion to main overexaggerated
[12:48] <siretart> I choose c) for now, but feel free to propose a symbol file as bug in debian with attachment ;-)
[12:48] <asac> siretart: can you post your process to the bug then?
[12:48] <asac> thanks
[12:49] <siretart> err
[12:49] <siretart> that the normal sponsoring review process
[12:49] <siretart> but fair enough
[12:59] <pitti> !regression-alert is cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
[12:59] <pitti> hm, that's what https://wiki.ubuntu.com/UbuntuBots documents..
[13:01] <pitti> sorry all for the noise; seems I'm not able to update this, will contact Jussi
[13:01] <jussi> !regression-alert is <reply>cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
[13:01] <jussi> :)
[13:02] <pitti> jussi: erm, wow -- that was fast :)
[13:02] <pitti> jussi: many thanks
[13:02] <jussi> although, lets just check
[13:02] <jussi> !regression-alert
[13:02] <pitti> \o/
[13:02] <jussi> it works!
[13:03] <smb> miraculous
[13:03] <jussi> pitti: the bot sometimes doesnt like long calls, not sure whats up with it. you did it correct, although it makes things easier if you include the <reply>
[13:03]  * pitti grabs megaphone "This was just a drill. Don't panic. As you were."
[13:04]  * ogra_cmpc shades his ears
[13:04] <seb128> pitti, way to stress me to start the week :p
[13:04] <smb> ogra_cmpc, Back to the classmate again? :)
[13:04] <ogra_cmpc> smb, my living room machine :)
[13:05]  * ogra_cmpc is having lunch
[13:05] <smb> :)
[13:15] <pitti> seb128: need to clean up my GTG list a bit :)
[13:59] <hyperair> dholbach: ping
[13:59] <dholbach> hyperair: pong
[14:01] <hyperair> dholbach: i'm going to be conducting a bug jam tomorrow, and was wondering if you had the template (or at least the background of) the "Ubuntu in 50 minutes" presentation around?
[14:01]  * hyperair needs to do some introduction slides
[14:01] <dholbach> you mean the text for the presentation?
[14:01] <hyperair> https://wiki.ubuntu.com/Presentations <-- the first link here
[14:01] <hyperair> no, the template
[14:01] <hyperair> like the background/formatting
[14:02] <dholbach> oh, I got that from henninge
[14:02] <dholbach> maybe he still has it
[14:02] <hyperair> hmm so i should contact him for the template?
[14:02] <dholbach> yeah
[14:02] <dholbach> https://wiki.ubuntu.com/Jams/Bugs?action=AttachFile&do=view&target=bug_report_triage_feb09.odp might be helpful too
[14:03] <hyperair> hmm let's see.
[14:04] <hyperair> dholbach: ah that's the glossyubuntu template. i was actually hoping for something that suits ubuntu's colour scheme post-branding-refresh
[14:04] <dholbach> hyperair: I meant the actual content
[14:04] <dholbach> :)
[14:05] <hyperair> ah!
[14:05] <dholbach> :-D
[14:05] <hyperair> yes, that helps very much =P
[14:05] <hyperair> thanks
[14:05] <dholbach> rock on!
[14:05] <dholbach> and enjoy the jam - will you post some pictures of it later on?
[14:07] <hyperair> dholbach: er where? =p
[14:07] <hyperair> er nevermind, i'll go register a flickr or picasa account or something
[14:08] <hyperair> dholbach: by the way, http://people.canonical.com/~dholbach/talks/Bugfixing%20in%20Ubuntu%20-%20German.odp <-- this gets 403.
[14:09] <dholbach> hyperair: sorry, fixed
[14:10] <hyperair> \o/ thanks
[14:26] <vish> hyperair: hey.. how big an event?
[15:41] <cnd> pitti: I see that linux-firmware-1.34.1 has been sitting in lucid-proposed for three weeks
[15:41] <cnd> is there something that needs to be done to push it out to release?
[15:41] <pitti> it has 2/4 verified
[15:41] <pitti> I guess it's "good enough"
[15:42] <pitti> the jaunty-proposed one is there for > 3 months already with zero feedback
[15:47] <cjwatson> pitti,slangasek: could one of you review the dpkg SRU in lucid-proposed, please?
[15:47] <ScottK> pitti: Would you please rescore kdepimlibs.
[15:47] <ScottK>  ... or cjwatson ^^^
[15:47] <pitti> ScottK: done
[15:47] <pitti> cjwatson: looking
[15:47] <ScottK> pitti: Thanks.
[15:48] <cnd> pitti: maybe the jaunty one could just be dropped
[15:49] <pitti> cjwatson: so this calls sync() once per package instead of fsync() once per file?
[15:53] <cjwatson> right, it turns out that's synchronous on Linux
[15:54] <cjwatson> and on many filesystems fsync() ends up nearly equivalent to sync() due to having to catch up with the journal anyway, as I (naively) understand it
[15:54] <cjwatson> so rather than write-sync-write-sync-write-sync, it's better to do write-write-write-sync
[16:13] <ion> http://fox.naurunappula.com/nn/1/096/359/s_607533.jpg
[16:13] <ion> Crap. Sorry, wrong channel
[16:21] <cjwatson> pitti: the -23 kernel looks not too bad regarding verification; what does your threshold normally tend to be for this stuff?
[16:22] <ogasawara> pitti: cnd pointed out that amd64 ddebs aren't getting published for recent kernels  - http://ddebs.ubuntu.com/pool/main/l/linux/ .  I'm not familiar with what needs to be done to fix that, any ideas?
[16:23] <smoser> we are in a freeze right now, right ?
[16:23] <cjwatson> smoser: no
[16:23] <smoser> i've not seen any announcements, but guessing based on alpha2 on thursday. wondering if there is somewhere i missed an announcemnt.
[16:23] <smoser> oh. ok.
[16:26] <cjwatson> guess I should send a warning
[16:26] <ogra> smoser, "soft freeze" its expected that you upload "carefully"
[16:27] <cjwatson> ogra: if we were in a soft freeze, there would have been a mail to ubuntu-devel-announce
[16:27] <ogra> cjwatson, hmm, i though we have soft freezes by default before every milestone
[16:27]  * micahg thought it would be tomorrow
[16:28] <cjwatson> ogra: well, I just said "smoser: no" above, didn't I? :P
[16:28] <ogra> indeed you did :)
[16:29] <cjwatson> we normally soft-freeze basically last thing Monday / first thing Tuesday before alphas
[16:53] <hyperair> vish: 2h 30m, the last event of tomorrow during the mosc 2010 (http://conf.oss.my)
[16:59] <bgamari> Should -work of hald-addon-cpufreq. After removing the file 10-cpufreq.fdi from /usr/share/hal/... it wasn't loaded anymore and my issue was done with.
[17:00] <bgamari> Scratch that; Should hald-addon-cpufreq be present in Maverick?
[17:01] <bgamari> It may very well be the reason why my cpufreq maximum frequency is 800 MHz
[17:01] <bgamari> There's definitely some major fail here either way
[17:02] <bgamari> I was under the impression, however, that we finally broke away from hal under 10.10
[17:11] <vish> oh.
[17:15] <JontheEchidna> bgamari: that package is no longer available in 10.10
[17:15] <JontheEchidna> from what I can see, anyhow
[17:21] <pitti> cjwatson: hmm, "gut feeling and talking to smb about regression reports", but I'd say something like #verified >= min(10, #bugs/2)
[17:21] <pitti> erm, "max"
[17:21] <pitti> if it's been in proposed for three weeks and we haven't heard about problems, then it can't be too bad
[17:21] <smb> Did I hear my name?
[17:21] <pitti> ogasawara: I'll check tomorrow morning (sorry, just finished a phone interview and need to run now)
[17:22] <pitti> smb: boo!
[17:22] <ogasawara> pitti: no hurry, thanks!
[17:25] <JontheEchidna> ah, its part of hal. If you have apps that still need hal, it'll be there, but the default Ubuntu install shouldn't have hal by default
[17:47] <cjwatson> kirkland: present for you, debian-installer 20100211ubuntu11
[17:47]  * kirkland hugs cjwatson 
[17:47] <kirkland> and goes look at his present
[17:48] <ogra> coudl some buildd admin bump livecd-rootfs so it starts in less than 5h ?
[17:49] <ogra> (i tried to get NCommander to do it but he doesnt seem to be around)
[17:49] <cjwatson> ogra: doing
[17:49] <ogra> merci
[18:01]  * kees just spent 30 seconds trying to figure out what regressed.  ;)
[18:03] <cjwatson> kees: hmm?
[18:03] <cjwatson> oh :-)
[18:03] <kees> cjwatson: :)
[18:09] <cjwatson> ogra: it's built now
[18:11] <bgamari> JontheEchidna: It's been uninstalled
[18:11] <bgamari> looks like banshee pulled it through the upgrade
[18:11] <bgamari> Anyone know of a way to determine which process is writing to a sysfs file?
[18:11] <JontheEchidna> yeah, looks like banshee depends on hal
[18:12] <bgamari> ftrace syscall_enter_open doesn't seem to catch it
[18:15] <ccheney> anyone know why i would have trouble sending keys to the ubuntu key server? it seems to hang for me
[18:15] <ccheney> or is the keyserver just broken?
[18:16] <geser> might be that the ubuntu key server has issues again
[18:25] <hyperair> jcastro: ping.
[18:26] <jcastro> pong
[18:27] <hyperair> jcastro: when conducting a bug jam, how do you usually avoid stepping on each others' feet?
[18:27] <kirkland> cjwatson: thank you thank you thank you!
[18:28] <hyperair> jcastro: like person X changes bug A, person Y performs a redundant action on bug A at the same time
[18:28] <jcastro> hyperair: section off groups of bugs to each group, so like, either by package, or by status
[18:29]  * vish had just set up hyperair for unassigned bugs and jcastro messed that up :p
[18:29] <hyperair> hehh
[18:29] <hyperair> jcastro: yeah, so like vish said, i was planning to work on unassigned bugs, since there are quite a lot of them, and we don't have much time.
[18:30] <cjwatson> kirkland: thought you'd like it
[18:30] <kirkland> cjwatson: very much so, can't wait to try it out
[18:34] <mdz> SpamapS, re: your memcached branch, the code in debian/preinst needs a test for the arguments to preinst
[18:34] <mdz> I see it was copied from gearman, and it looks like gearman is buggy in this respect also
[18:35] <SpamapS> mdz: does seem like this would be a useful addition to debhelper so we stop making these mistakes .. since gearman copied it from mysql... ;)
[18:35] <mdz> SpamapS, indeed
[18:35] <cjwatson> it's being added to dpkg, if this is what I think you mean
[18:35] <cjwatson> conffile handling?
[18:35] <mdz> cjwatson, adding a user
[18:36] <cjwatson> ah ok
[18:36] <mdz> but this is a general issue with maintainer scripts, forgetting the tests
[18:37] <mdz> the mysql one even has the comment at the top "summary of how this script can be called" but ignores it ;-)
[18:43] <SpamapS> mdz: another thing that would be awesome would be if pbuilder simulated failures to test the abort states of the maintainer scripts.
[18:46] <mdz> SpamapS, sounds like the sort of thing which would fit into piuparts if it isn't there already
[20:14] <leonpegg> Hello all I know this is not the place to ask but ubuntu-app-devel were unable to help, could anyone here help me with packaging some sourcecode ? Situation (attempting to package the php-gtk2 source into a source package except need it to output multipul binary packages from the one source tree)
[20:14] <leonpegg> would be happy to be pointed to the direction of a tut on it (but cant find one myself)
[20:15] <directhex> leonpegg, try #ubuntu-motu for more beginner packaging help
[20:15] <lifeless> and/or #ubuntu-packagng
[20:15] <leonpegg> Thanks guys :DF
[20:15] <geser> #ubuntu-packaging
[20:16] <Laney> what's that channel for?
[20:16] <Laney> Is -motu no longer the place?
[20:17] <leonpegg> seems as if both rooms have people in :D
[20:17] <leonpegg> looks like motu is for offical packages and packaging is for ppa's and the likes
[20:19] <directhex> asac, any idea when you'll be able to look at the downstream mono arm breakage? i completely give up on getting a build environment going without real hardware, it's just not happening, and i've spent about 2 days on this so far with reality fighting against me. best i can do is reverting whichever ubuntu patches broke building in debian
[20:23] <ogra_cmpc> directhex, sudo apt-get install qemu-arm-static && sudo qemu-debootstrap --arch armel maverick maverick-chroot && sudo chroot maverick-chroot
[20:24] <ogra_cmpc> directhex, oh, wait, you do mono, the above works for everything but mono thanks to boehm gc
[20:26] <TylerGalt> Hello everyone, while browsing https://help.ubuntu.com/community/HowToMD5SUM , I stumbled on this sentence: "However this almost always NOT be the same hash as the iso image that was burned to the disk"
[20:26] <TylerGalt> While english is my second language, I feel like a verb is missing, but I'm not sure how best to correct this (I just created an account on the wiki). Would "However this *will* almost always NOT be the same hash as the iso image that was burned to the disk" work better in your opinion? Or should we revamp the whole sentence?
[20:27] <JontheEchidna> "However this will almost always..."
[20:27] <JontheEchidna> yes
[20:27] <TylerGalt> cool, thanks :)
[20:27] <JontheEchidna> (sorry, lag)
[20:30] <TylerGalt> (no problem :) I wanted to double-check: it would have been dumb to correct the sentence to introduce a grammatical error. Goodbye everyone, and thanks for working on Ubuntu (love it) )
[20:37] <Rinsmaster> Just getting an opinion here: Is it a bug that nautilus freezes when clicking properties on an infinite loop postscript file?
[20:44] <achiang> anyone know the best forum for casper questions?
[20:44] <ccheney> can someone promote bugs 589993 and 589995
[20:44] <ccheney> doko__, do you happen to be awake to promote the above mentioned MIRs ?
[20:51] <ScottK> pitti or cjwatson: Would you please rescore kdebindings and kdebase-workspace.
[21:14] <kblin> er, durn, wrong #
[21:15] <ScottK> Thanks whoever bumped them.
[21:16] <cjwatson> ScottK: done
[21:16] <cjwatson> ScottK: do they need retried on amd64/armel?
[21:17] <ScottK> cjwatson: I just retried amd64.  Would you please bump that one?
[21:17] <ScottK> cjwatson: armel would fail now because kdepimlibs isn't done.  I'll retry them later for armel.
[21:17] <ScottK> Sorry about that one.
[21:18] <ScottK> https://wiki.kubuntu.org/Kubuntu/Ninjas/DependencyGraph is the rosetta stone for KDE package building if you ever wondered the sequence.
[21:25] <geser> looks simplier than the haskell ones
[21:27] <ScottK> Yes.  Definitely.
[21:27] <ScottK> Those are totally insane.
[21:35] <Laney> :)
[21:39] <vish> bdrung: audacity or audacious?  audacious has the icon
[21:40] <bdrung> vish: audacity - it has the icon
[21:40] <vish> hmm , odd ,audacity doesnt show icon for me too
[21:40] <bdrung> i am on amd64
[21:41] <vish> i386 here
[22:58] <zyga> where can I find older ubuntu releases?
[22:58] <soren> How old?
[22:58] <zyga> hardy+
[22:58] <soren> Right next to the current ones.
[22:58] <zyga> I tried checking cdimage.ubuntu.com but it seems /releases/ keeps going nowhere
[22:58] <soren> For really old releases, see http://old-releases.ubuntu.com/
[22:59] <zyga> http://cdimage.ubuntu.com/releases/hardy/release/
[22:59] <soren> Try http://releases.ubuntu.com
[22:59] <soren> That's where we put releases.
[22:59] <zyga> oh, thanks
[23:48] <ScottK> cjwatson: Would you please rescore kdebindings kdebase-workspace again (to pick up armel).
[23:49] <TheMuso> c
[23:49] <TheMuso> gah wrong tab