[01:20] <slangasek> ScottK: boost MPI> well, it's a long MIR chain if we pull that all in; I'm not convinced that's what we want to do
[01:31] <ScottK> slangasek: The package in question is in Universe.  I was thinking maybe finish the 1.40 -> 1.42 transition in Main and then add the MPI stuff back to 1.40 in Universe.
[01:55] <ajmitch> ScottK: you want to keep 1.40 around?
[01:55] <ScottK> ajmitch: Not particularly, but there's at least one package using MPI now and so it'd be an alternative to MIR for the entire MPI stack.
[01:56] <ajmitch> then I'd better merge it at some point
[01:56] <ajmitch> unless you prefer to do it
[01:56] <ScottK> No.  I never "prefer" to touch Boost stuff.
[01:56] <ajmitch> I was afraid of that
[01:56] <ScottK> We need to drop it to Universe first if it hasn't already.
[01:57] <Cuervo> foes the c library offer any interfaces to kvm?
[01:57] <Cuervo> *does
[01:57] <ajmitch> it's still in main at the moment
[01:57] <Cuervo> and if so, how do I access them?
[01:57] <ScottK> It may not need to be/
[01:57]  * ScottK investigates
[01:58] <ajmitch> it still had a few rdepends when I looked last week, but I didn't check if any were in main
[01:58] <ScottK> None are in Main.
[01:59] <ScottK> slangasek: Unless you have a better idea for dealing with MPI, would you please demote all the boost1.40 stuff to Universe and we'll get it restored that way (it's in compononet mismatches)
[02:00] <ajmitch> if I'm to do the merge, want me to add in the MPI stuff at the same time?
[02:00] <ScottK> ajmitch: Yes.  Please.
[02:01] <ScottK> No particular reason to wait either.  It should just dep wait until it's demoted.
[02:01] <ajmitch> it's the majority of the changes carried from debian at the moment
[02:02]  * andreserl TestDrive PyGTK Front-end Demo Released!
[02:03] <ajmitch> andreserl: how many channels was that in? :)
[02:05] <andreserl> ajmitch, uhmmm 15?? most of them #ubuntu-* :)
[02:06] <ajmitch> andreserl: posted to planet ubuntu yet?
[02:06] <andreserl> ajmitch, I'm about to :)
[02:07] <ajmitch> since you provided no url or screenshots for me to look at
[02:19] <andreserl> ajmitch, yeah I'm finish writing the blogpost, though there are screenshots: http://www.roaksoax.com/2010/06/gsoc-update-of-the-week-testdrive-pygtk-front-end-3 http://www.roaksoax.com/2010/05/gsoc-update-of-the-week-testdrive-pygtk-front-end-2
[02:21] <ajmitch> looks good, I might need to try it out :)
[02:29] <superm1> slangasek, hm, that (otherwise) successful build appears to have a livefs that's about 10 days old
[02:30] <superm1> even though the livefs from today was success filled
[02:56] <andreserl> ajmitch, http://www.roaksoax.com/2010/06/gsoc-update-of-the-week-testdrive-pygtk-front-end-4
[03:02] <ajmitch> andreserl: nice, so it does work well with virtualbox?
[03:38] <andreserl> ajmitch, it works :)
[05:25] <orangey> hello all!
[05:30] <orangey> hmm.
[05:30] <orangey> any tips on testing out the latest alsa from lucid?
[05:52] <TheMuso> orangey: When you say testint out, what do you mean exactly?
[06:05] <orangey> TheMuso: well, I'm using lucid and am having difficulties with my sound card, so wanted to put the new driver set in place.
[06:05] <orangey> for which, yes, there are PPAs
[06:06] <orangey> but on the face of it, doesn't seem like it's working
[06:06] <TheMuso> orangey: Right, there are some unusual build failures that haven't yet been solved, and are unfortunately something that upstream will have to resolve, at least unless another member of the audio team manages to do so.
[06:07] <TheMuso> orangey: The only way to test newer also code atm is to build your own kernel, or use one of the kernel team's mainline builds.
[06:09] <orangey> TheMuso: gotcha
[06:09] <orangey> I'm trying this now, but it's out of the #devel territory by now: http://ubuntuforums.org/showthread.php?p=6589810
[06:15] <TheMuso> orangey: I don't endorce that method, as there is a chance it will break something.
[06:15] <orangey> TheMuso: I've looked through the shell and agree ; )
[07:00] <dholbach> good morning
[07:05] <slangasek> ScottK: ah, boost1.40 demoted, then :)
[07:20] <slangasek> superm1: ah; the livefs buildds moved, but the script to download the built images isn't in sync. :/ fixing
[07:23] <superm1> slangasek, ooh fun.
[07:26] <slangasek> superm1: running another test
[07:26] <superm1> slangasek, mkay thanks
[07:47] <orangey> hmm.
[07:47] <orangey> is there any way for me to figure out the ID of an alsa device?
[07:47] <orangey> i.e., the microphone of sound card 0?
[07:56] <TheMuso> orangey: What do you mean by id?
[08:00] <orangey> the identifier like "hw0,0"
[08:00] <TheMuso> manjo: You can't refer to a sound card's indivudla inputs/outputs like that, at least for the most part.
[08:01] <TheMuso> manjo: sorry not meant to go to you.
[08:01] <TheMuso> orangey: ^^
[08:01] <orangey> : )
[08:01] <orangey> TheMuso: not true. you CAN
[08:01] <orangey> e.g., in pulse configs
[08:03] <hyperair> hmm what's the difference between gstreamer0.10-fluendo-mp3 and gstreamer0.10-fluendo-plugins-mp3-partner?
[08:07] <TheMuso> orangey: Please explain then.
[08:10] <orangey> TheMuso: well, the card is 0
[08:10] <orangey> i.e., hw:0
[08:10] <orangey> then the particular subdevice or whatever is ,whatever
[08:10] <orangey> so that the default device is usually hw:0,0
[08:11] <orangey> is that what you're asking?
[08:17] <TheMuso> orangey: No, you asked about how one could use the mic etc via hw:0, and I said it was not possible.
[08:17] <TheMuso> orangey: It is possible by setting the capture device through the mixer, and recording from hw:0 etc.
[08:17] <orangey> TheMuso: pulseaudio is incorrectly detecting my internal mic
[08:17] <orangey> I want to help it by pointing it to the correct one
[08:18] <orangey> if I knew its internal alsa ID, I could
[08:20] <pitti> Good morning
[08:21] <TheMuso> orangey: run alsamixer and look for the string that identifies your mic.
[08:21] <TheMuso> orangey: Then you need to look at the files in /usr/share/pulseaudio/alsa-mixer/ to adjust things appropriately.
[08:23] <orangey> intriguing
[09:30] <geser> Riddell: could you please kill http://people.canonical.com/~ubuntu-archive/NBS/rdoc? All versioned dependencies (without an alternative) on rdoc should be gone and ruby provides rdoc. The real rdoc deb prevents that several ruby packages can currently get build in maverick as ruby conflicts rdoc and the buildds try to install both.
[09:45] <pitti> geser: thanks for checking! killed
[10:27] <nigelb> We now have http://wiki.debian.org/DerivativesFrontDesk
[10:28] <dholbach> and a debian-derivatives mailing list
[10:32] <nigelb> dholbach: worth adding to the Debian page on w.u.c?
[10:32] <dholbach> Also… we have an Ubuntu Developer Week schedule to fill: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep - if you're interested in giving a session or suggesting one, please go ahead and add it :)
[10:32] <dholbach> nigelb: totally
[10:34] <nigelb> dholbach: you should probably also write to -devel (about front desk and developer week)
[10:34] <dholbach> nigelb: or you!
[10:35] <dholbach> I'll write about UDW :)
[10:35] <nigelb> dholbach: my mails get moderated :/
[10:36] <cjwatson> that can be rectified
[10:36] <nigelb> doh, of all the times for you to pop in :P
[10:37]  * nigelb goes to write mail
[10:42] <cjwatson> tell me when you've sent it
[10:55] <hrw> hi
[10:55] <hrw> dholbach: alive?
[10:57] <geser> cjwatson: should bugs using your openssh PPA on lucid also be filed in LP?
[10:58] <cjwatson> geser: yes please, just mark them clearly
[10:59] <cjwatson> geser: (see http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2010-05-10-openssh-5.5p1-for-lucid.html)
[10:59] <dholbach> hrw: yep
[11:00] <hrw> dholbach: as part of "Ubuntu Developer Week" would be nice to have a talk about blueprints/specs/workitems - what they are and how they are supposed to be used
[11:01] <dholbach> hrw: can you add it as a suggestion to the bottom of the page?
[11:01] <dholbach> hrw: I guess it could be useful
[11:02] <hrw> added
[11:02] <hrw> dholbach: took me a while to find out about them
[11:02] <dholbach> hrw: excellent, thanks
[11:02] <jpds> 3
[11:03] <hrw> dholbach: and I still think that they are made wrong way
[11:03] <dholbach> hrw: what exactly do you think is wrong? the format of specifications? the way we track work items?
[11:04] <geser> cjwatson: I just checked and the version in lucid has the same problem (filing a bug anyways)
[11:05] <hrw> dholbach: using whiteboard for work items + status + notes. it should be split into work items (handled like bugs but not being bugs), status/notes should be wiki (so history is present)
[11:05] <cjwatson> everyone involved acknowledges that work items are a hack
[11:05] <hrw> dholbach: and status of how many workitems exists and how many are completed should be part of LP not external service
[11:06] <dholbach> hrw: I filed a bug about it part 1 of your complaint
[11:06] <dholbach> I can try to find it
[11:06] <dholbach> but I'm sure the LP folks would love help with that
[11:06] <hrw> from my perspective as new developer in ubuntuland it looks like hack on hack which everyone is fine with
[11:06] <dholbach> and I'm sure they'd agree
[11:07] <hrw> dholbach: I can share ideas not code
[11:07] <dholbach> hrw: it's quite easy to criticise the LP team
[11:07] <hrw> dholbach: I know, they do lot of great work
[11:07] <dholbach> (and give them yet another idea :))
[11:08] <cjwatson> hrw: the perfect is sometimes the enemy of the good
[11:08] <hrw> and I know that I can create a bug for each work item to have a way to track each of them
[11:08] <cjwatson> having something available now which is distinctly suboptimal but works is better than having a perfect design which nobody has time to implement
[11:08] <hrw> cjwatson: thats also true
[11:08] <cjwatson> and we've been consistently told that blueprints is unmaintained
[11:08] <DktrKranz> mvo: hi! what do you think about uploading gdebi to unstable and sync it to maverick shortafter? There are some good fixes already. Or do you prefer waiting to merge python-apt branch?
[11:08] <cjwatson> and yet we're fairly committed to using it, so it makes sense to make do
[11:09] <mvo> DktrKranz: sync sounds good, I can do the python-apt merge today I think
[11:09] <mvo> DktrKranz: will you be able to do the debian upload?
[11:09] <dholbach> hrw: bug 578263 was what I was talking about
[11:09] <cjwatson> it was all done outside of the LP team, so there's nothing stopping somebody else implementing something better
[11:09] <DktrKranz> mvo: sure thing
[11:09] <mvo> thanks .)
[11:09] <hrw> thx
[11:09] <DktrKranz> not before this evening, though :)
[11:09] <cjwatson> but that's a little different from saying that we shouldn't be using what we have
[11:11] <hrw> cjwatson: I did not said 'lets abandon blueprints'
[11:11] <DktrKranz> mvo: mind give me a ping when you perform the merge?
[11:12] <mvo> DktrKranz: sure
[11:12] <DktrKranz> thanks ;)
[11:18] <nigelb> cjwatson: sent :)
[11:20] <cjwatson> nigelb: moderated, and your postings should be accepted in future.  (please send plain-text mail rather than alternative text+HTML, though.)
[11:20] <ajmitch> there has been a little bit of work done on blueprints, hopefully it'll get in
[11:20] <nigelb> cjwatson: its the gmail thingie.  Im away from my evolution.  It formats it correctly
[11:20] <ajmitch> and yeah, using the whiteboard for tracking work items is a bit of a nasty hack :)
[11:21] <nigelb> ajmitch: I'd love to see all blueprints where I have been assigned a task.  NOw I have to keep a seprate list
[11:21] <ajmitch> nigelb: yes, that'd make sense - I think the original intent was to have lots of blueprints linked through their dependencies
[11:22] <nigelb> ajmitch: what happens now is if the blueprint is not part of series, it doesn't get shown anywhere.  I wish we had a "collect all" page where all blueprints discussed at uds would turn up
[11:23] <ajmitch> an interim step to get rid of the screen scraping in the work items tracker is to expose those properties on blueprints via the API
[11:23] <nigelb> +1 to that
[11:24] <nigelb> like having a feature of assigning people to each task in the blueprint
[11:24]  * ajmitch hopes that exposing some of the API can land in the next month or so
[11:24] <mvo> DktrKranz: i just checked and the maverick python-apt version should be very up-to-date, no code changes in the merge
[11:27] <nigelb> ajmitch: we should pester jorge or someone from LP team
[11:28] <ajmitch> nigelb: for which part?
[11:28] <nigelb> ajmitch: for the LP-related part
[11:28] <ajmitch> I mean for which part of blueprints? the basic API stuff is almost there
[11:29] <nigelb> if we start a dialogue now, we can have something by next uds
[11:29]  * ajmitch has looked at it a bit
[11:31] <nigelb> ajmitch: ah, I didn't know you worked on LP in your free time :)
[11:32] <ajmitch> nigelb: infrequently :)
[11:32] <nigelb> ajmitch: rocking :)
[11:32] <ajmitch> as in, I haven't got anything in yet
[11:34]  * nigelb hasn't touched LP (yet :D)
[11:36]  * apachelogger pokes pitti with http://paste.ubuntu.com/453322/ and hopes some thoughts on that matter will fall out of him ^^
[11:37] <apachelogger> usb-creator has the same problem supposedly
[11:37] <apachelogger> or really anything created by intltool I would argue
[11:39] <pitti> apachelogger: I know that a thing like "context" exists in translations, but why does it need to be mandatory?
[11:39] <pitti> I'm afraid I don't quite understand the problem
[11:42] <apachelogger> pitti: It is not mandatory it just happens to be used in the KDE templates, hence our desktop-file-translation-from-mo patches do a context+value lookup instead of just value
[11:43] <apachelogger> Suffice to say that a context would probably also help translators in this particular case, since one might not know that a comment is really a comment unless launchpad tells one that this is a comment ;)
[11:43] <pitti> apachelogger: i. e. we need to fix the build system to add a context to the strings extracted from the .desktop.in?
[11:44] <apachelogger> pitti: I do think so.
[11:44] <pitti> (that would need a new option in python-distutils-extra, I figure)
[11:46] <apachelogger> pitti: Do you want a bug report about it?
[11:47] <pitti> please, with the details
[11:48] <apachelogger> pitti: against python-distutils-extra?
[11:48] <pitti> right
[11:48] <pitti> that should provide the functinoality
[11:49] <pitti> and then we just need to set the context name or enable the option in jockey
[11:49] <apachelogger> ok, will report in a bit
[12:11] <juliank> didrocks: You can also contact me here on dh-autoreconf stuff.
[12:11] <didrocks> juliank: oh perfect, that will be quicker next time :)
[12:12] <didrocks> juliank: thanks for your work on dh-autoreconf btw, it's really great and avoid generating an autoreconf patch each time :)
[12:12] <ajmitch> juliank: were you still planning to do http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559752 ?
[12:18] <juliank> ajmitch: If you want, you can take them. I'm already maintaining the whole high-level package management GNOME world and writing a new package manager, so I think I have enough. If you want to, I can co-maintain it.
[12:18] <ajmitch> juliank: alright
[12:18] <ajmitch> it's a bit easier now that 2.6 is default in debian
[12:18] <ajmitch> you seem to have a bit on your plate at the moment :)
[12:19] <juliank> ajmitch: There are also some licensing issues to sort out first (https://bugs.edge.launchpad.net/ubuntuone-storage-protocol/+bug/583335) before this can go into Debian.
[12:20] <juliank> That was probably the reason why I paused working on it.
[12:20] <ajmitch> right, thanks for the heads-up on that one
[12:21] <ajmitch> looks like it just got fixed, too
[12:23] <didrocks> juliank: I saw you new feature. I don't see for now package where we would need it for now, but it sounds good :)
[12:23] <juliank> mvo: Do we want to sync sessioninstaller? (I took the Ubuntu tarball, so it should work)
[12:24] <juliank> The tree being at lp:~juliank/sessioninstaller/debian-sid
[12:24] <juliank> if you want to merge it.
[12:32] <apachelogger> pitti: bug 597216
[12:32] <pitti> apachelogger: thanks
[12:42] <mvo> juliank: hello! sounds good, I will do a sync request. thanks for the update
[13:45]  * apachelogger leaves bug 290351 on the desk of cjwatson ;)
[13:45] <Riddell> can't say I'm fussed about that issue myself
[13:45] <apachelogger> cjwatson: supposedly we just need to have a different casper.conf installed for kubuntu or whoever wants to have a different setup?
[13:47] <cjwatson> I can't deal with it now, sorry
[13:47] <apachelogger> k :)
[14:36] <engla> DktrKranz: I see you are involved in packaging shotwell. that's a great program, thanks for doing that.. :)
[14:39] <DktrKranz> hi engla! yeah, currently doing porter work to let it build everywhere ;)
[14:41] <engla> debian has very ambitions goals in getting it to work on even kfreebsd, I imagine many packages can be tricky
[14:42] <DktrKranz> that is easy, I just have to adjust patch originally provided by "regular" porters ;)
[14:43] <DktrKranz> and once 0.6.0 is released, I plan to get it in sync with Maverick (it's better to avoid duplicating efforts)
[16:15] <sri> so, I have hald running on lucid and I suspect it is an artifact of an apt-get dist-upgrade from karmic.. how do I get off of hald?
[16:17] <sri> actually I'm probably asking the wrong channel. sorry about that.
[16:28] <DktrKranz> mvo: cool, so merge should be easy
[16:43] <ricotz> seb128, hello, will maverick ship a gsettings enabled gconf?
[16:43] <seb128> ricotz, hi, no
[16:44] <seb128> ricotz, desrt said that backend should not be shipped in distros
[16:44] <seb128> ricotz, it's hackish and made for hackers porting their code not for being used
[16:44] <ricotz> seb128, ok, thank you
[16:44] <seb128> you're welcome
[16:44] <seb128> ricotz, do you need it for something?
[16:45] <ricotz> seb128, gnome-shell currently using it and therefore settings are broken
[16:46] <seb128> oh ok
[16:46] <seb128> I guess talk with desrt and g-s guys and get them to agree on what to do
[16:47] <ricotz> alright
[16:47] <seb128> I'm fine with shipping the gconf backend if that's what we should do
[16:48] <seb128> but he told us to not ship it at uds
[16:48] <ricotz> seb128, i was thinking to put an enabled gconf into the gnome-shell ppa
[19:06] <qense> directhex: Did you see the bug reported against banshee-community-extensions already? :) banshee-extension-appindicator needs to be rebuilt on Maverick because of changes to the Mono bindings of libappind on 0.2.1
[19:06] <directhex> qense, i didn't see the bug. is appind all fixed up now? i know hyperair was contributing to that
[19:07] <hyperair> qense: er i just test built, forgot to upload.
[19:08] <qense> directhex, hyperair: It seems the problem is solving itself already now. :)
[19:08] <qense> hyperair: thanks!
[19:08] <hyperair> directhex: what do you do with a library that doesn't break ABI in terms of interfaces/symbols, but screws itself up anyway through some weird exceptions or other?
[19:08] <hyperair> Bug #597283
[19:08] <hyperair> directhex: ^^
[19:09]  * hyperair staggers into bed
[19:09] <qense> hyperair: sleep well
[19:11] <directhex> hyperair++
[19:59] <ccheney> doko_, i was wondering if you were going to be able to process the OOo related MIRs I filed about 2 weeks ago?
[20:00] <ccheney> asac, perhaps reassigning them to someone else if doko is overloaded would be helpful? :)
[20:11] <apw> slangasek, the only bit of our installer which seems to touch debconf is the fragment below, and i am not convinced that we are therefore using it at all really
[20:11] <apw> use Debconf::Client::ConfModule qw(:all);
[20:11] <apw> version('2.0');
[20:11] <apw> my $capb=capb("backup");
[20:15] <ajmitch> ScottK: I can see why you didn't want to touch boost
[20:23] <slangasek> apw: you're loading the module; this is only guaranteed to succeed if the debconf package is in installed state; either the pre-dep should be added so the package manager knows what order to configure things in, or the references should be dropped from the preinst
[20:28] <apw> slangasek, yeah i am trying to ask if you concur that actually we arn't using it, and therefore ripping it out is the right thing to do to solve the error
[20:40] <cjwatson> apw: a dusty memory somewhere indicates that, although debconf isn't used directly by the kernel preinst, it was needed in order to make things work when /etc/kernel/preinst.d scripts used debconf
[20:40] <cjwatson> this may be nonsense
[20:40] <cjwatson> but you might want to look through the history for that
[20:41] <cjwatson> and perhaps grep the archive for /etc/kernel/preinst.d scripts and see what they do
[21:04] <slangasek> cjwatson, apw: there was some issue surrounding dkms, yeah, but I honestly don't remember if this preinst usage was related to that
[21:36] <lex79> someone can look at this: https://launchpad.net/ubuntu/+source/libvdpau/0.4-5/+build/1790677
[21:36] <lex79> libvdpau needs ia32-libs to build which is in universe
[21:39] <lex79> and ffmpeg needs libvdpau to build...so it ftbs only on amd64
[21:39] <lex79> https://launchpad.net/ubuntu/+source/ffmpeg/4:0.6-1ubuntu1/+build/1796084
[22:37] <lamont> Building database of manual pages ... <-- I want that to go faster, dangit
[22:47] <geser> I disabled that for my pbuilder :)
[22:49] <geser> lex79: I've strong doubts that ia32-libs comes even near main
[22:55] <soren> geser: It used to be in main. Back in the old days. :)
[22:57]  * micahg though ia32-libs would be going away with multiarch
[22:57] <micahg> *thoguht
[22:57] <micahg> ugh :-/
[23:10] <cjwatson> lamont: feel free to suggest ways it could be further optimised ...
[23:14] <arand> cjwatson: For btrfs in installer, which is the relevant package to track, d-i? Some of the partman-* packages? Or a bzr branch somewhereabouts?
[23:15] <arand> (If you're just wanting to keep up with any news)
[23:17] <cjwatson> partman-btrfs
[23:18] <cjwatson> not that I can guarantee any given change will affect that.  the installer's modular, there isn't necessarily a single package to track
[23:20] <arand> Right, I was just wondering because of the announcement, and then not finding any mention in the installer-related changelogs I could find. Thanks!
[23:23] <cjwatson> arand: also, http://lists.debian.org/debian-boot/2010/06/msg00088.html and thread