[00:04] <lool> james_w: I think not, these are not public python modules, just implementation details
[00:05] <lool> james_w: It's not python-xdeb, but really just xdeb
[00:07] <fqh> Hi, If I install OS from 10.10's daily build iso, it means that I get a latest 10.04?
[00:10] <fqh> I install one system from 10.04's ISO, then it should be updated immediately. And I install another system from 10.04's iso,  then I will do the update work too. I want to get a latest 10.04's ISO directly.
[00:28] <kirkland> slangasek: okay, i think i'll work on a monolithic file first, get that working, and then work on the seed separation into common components
[00:29] <slangasek> fair enough
[00:29] <cjwatson> fqh: um, no, if you install the OS from a 10.10 image then you get whatever state the thing that's to become 10.10 is currently in :-)
[00:30] <fqh> cjwatson: Thanks, got it
[00:31] <cjwatson> slangasek: maybe something kind of similar - doesn't look quite the same?
[00:32] <cjwatson> ScottK: done
[00:32] <slangasek> cjwatson: huh, ok; I thought this was one that was fixed already
[00:33] <cjwatson> slangasek: I don't think I have any unsubmitted patches for plymouth at the moment
[00:34] <cjwatson> slangasek: actually, it does look like one I have
[00:34] <slangasek> oh; submitted upstream but not pushed to the package?
[00:34] <cjwatson> slangasek: http://paste.ubuntu.com/450352/ is what's in my local tree and seems similar
[00:34] <slangasek> cool
[00:34] <cjwatson> may not be in the package yet
[00:35] <cjwatson> yes, and that went upstream as c859e580a197a121bb5666fe2628b38ec88da9e4
[00:36] <cjwatson> it was the day before 10.04 released so wasn't worth shoving in
[00:36] <slangasek> right :)
[00:39] <cjwatson> kirkland: it'd make my life so much easier if our qemu packaging matched Debian's a little more :-(  specifically, if there were a /usr/bin/qemu-system-i386 somewhere
[00:40] <kirkland> cjwatson: understood, will be happy to comply
[00:40] <cjwatson> want a bug?
[00:40] <kirkland> cjwatson: hallyn should be owning qemu-kvm + libvirt this cycle, and I'll help out
[00:40] <kirkland> cjwatson: yes, please
[00:40] <cjwatson> mkay
[00:40] <cjwatson> thanks
[00:41]  * cjwatson patches grub2 in the meantime.  it could probably do with a configure check or something
[00:41] <kirkland> cjwatson: we're hoping to get to basing qemu-kvm on debian
[00:41] <kirkland> cjwatson: unfortunately, they didn't base their qemu-kvm package on ours
[00:41] <kirkland> cjwatson: so there is a some diff
[00:41] <kirkland> cjwatson: i gotta get to the bottom of that
[00:42] <ScottK> cjwatson: Thanks.
[00:42] <kirkland> cjwatson: i'd like to create a live-uec seed (per our discussion at UDS, and per a work item i have for Alpha2)
[00:42] <kirkland> cjwatson: this is my first crack at it: http://paste.ubuntu.com/450355/
[00:42] <kirkland> cjwatson: as slangasek suggested, i'd like to prune the commonalities between this one and the desktop one into a common seed
[00:43] <kirkland> cjwatson: and then desktop could add openoffice, langpacks, multimedia, etc.
[00:43] <kirkland> cjwatson: and this one would add eucalyptus-*
[00:43] <cjwatson> I'd actually rather not have a common seed there
[00:43] <cjwatson> I think it will wind up being kind of artificial and hard to maintain
[00:44] <cjwatson> I know we do use common seeds in some places, but they work best when there's a clear concept of what they mean, and worst when they just exist to be a sort of set intersection and nothing else
[00:44] <cjwatson> and I think this would end up being more of the latter
[00:44] <cjwatson> I don't really see anything wrong with listing things explicitly here
[00:45] <cjwatson> it would be pretty confusing for the desktop folks, because they'd need to know about what belongs on live-uec images in order to work out where to add packages, you see, and I don't think they should have to know that
[00:46] <cjwatson> your approach seems OK, though I think there are some header tweaks that could stand to be made, like adding eucalyptus-simple-cluster or something to the Task-Key: list
[00:49] <kirkland> cjwatson: okay, fair enough
[00:49] <kirkland> cjwatson: can i push this in its current form, as an untested draft, safely to bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.maverick/ ?
[00:49] <kirkland> cjwatson: ie, will it automatically get "picked up" by anything?
[00:52] <cjwatson> mm, best to use a private branch I think
[00:52] <cjwatson> the archive works off that branch automatically
[00:53] <kirkland> cjwatson: can do
[00:53] <cjwatson> make sure to add an entry to STRUCTURE as well (and not at the end - put it in some place that sort of matches its depth in the dependency tere)
[00:53] <kirkland> cjwatson: alright, so how do I "test" this?
[00:53] <cjwatson> *tree
[00:53] <cjwatson> man germinate, you can run it off a local directory quite easily
[00:54] <cjwatson> the man page should be enough to work it out; if not, file a bug :-)
[00:54] <kirkland> cjwatson: http://paste.ubuntu.com/450362/
[00:54] <cjwatson> you'll get a pile of output files in the current directory, and you can look at the one called 'live-uec'
[00:54] <kirkland> cjwatson: okay, i was toying with germinate
[00:55] <cjwatson> that seems fine but how come it doesn't inherit from uec?
[00:55] <cjwatson> oh, not quite fine
[00:56] <cjwatson> you should also make some other seed (worst case, 'supported') inherit from live-uec, otherwise it's kind of orphaned and packages in it aren't guaranteed to be considered for main
[01:02] <kirkland> cjwatson: good call, should inherit uec
[01:32] <m3ga> Sarvatt: found a driver for the touchscreen of that tablet. its another crappy binary only driver, but if i can get it working in can snoop the usb and write a real driver.
[01:37] <TheMuso> m3ga: Any luck with the wifi?
[01:38] <m3ga> no, i'll tackle the wifi after i get the touchscreen working. it also has a crappy binary only driver that should be easy to reverse engineer by snooping the usb.
[01:54] <TheMuso> ah ok.
[04:11] <micahg> ScottK: is there a reason you're not in -motu?
[04:12] <ScottK> micahg: Yes.  See the ubuntu-motu ML.
[04:12] <micahg> ah, k, will check, sorry
[04:12] <ScottK> No problem.
[04:13] <micahg> ScottK: ah, can I ask you about something in here then that you previously discussed with me
[04:13] <ScottK> micahg: Certainly.
[04:14] <micahg> ScottK: k, do you remember discussing timeout with me?  apparently there's a buildd bug 594916 that seems to require a transitional package in timeout until it's fixed, what do you think?
[04:15]  * ScottK looks
[04:18] <ScottK> micahg: You didn't have a new enough coreutils on armel yet.
[04:18] <ScottK> (you do now)
[04:19] <ScottK> Versioned provides are unsupported (and that's a long standing issue).
[04:19] <micahg> ScottK: in Lucid there isn't a high enough version
[04:19] <ScottK> That error is on Lucid?
[04:19] <micahg> ScottK: yes, the idea is to have one build for all versions
[04:19] <micahg> that works with a transitional package for maverick for timeout
[04:20] <micahg> or the versioned build deps
[04:20] <ScottK> Where's your package?
[04:21] <micahg> ScottK: this is for chromium: https://code.edge.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head
[04:22] <ScottK> micahg: I don't see coreutils or timeout in http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head/annotate/head:/debian/control
[04:24]  * micahg wonders what happened
[04:27] <micahg> ScottK: http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.beta/annotate/head:/debian/control
[04:27]  * micahg had the wrong branch
[04:27] <ScottK> Looking again
[04:30] <ScottK> micahg: It's a bit late here, but I'd have thought that would work.
[04:30] <micahg> ScottK: me too :)
[04:30] <ScottK> Maybe wgrant has a suggestion.
[04:36] <micahg> ScottK: thanks
[04:37] <ScottK> No problem.
[04:37] <ScottK> Wish I had a proper answer.  It's just been a while since I had to wrestle through one of these.
[04:37] <micahg> ScottK: np, it might be a moot point now that I think about it, he wants to drop the test suite that requires the binary
[04:38] <micahg> that's why it wasn't in .head
[04:59] <wgrant> micahg: Can't you just flip it to 'timeout | coreutils (>= 8.0)'?
[04:59] <micahg> wgrant: I think he tried it both ways
[05:00] <micahg> wgrant: I think there's a bug in the buildd, bug 594916
[05:01] <wgrant> There is a bug, yes.
[05:01] <wgrant> It's been around for a long time.
[05:02] <wgrant> But you should be able to work around it by swapping the disjuncts.
[05:02] <micahg> wgrant: will pbuilder behave differently than the buildds
[05:03] <wgrant> It depends on which resolution algorithm you configure pbuilder to use.
[05:03] <wgrant> Launchpad uses a modified version of sbuilds from a few years ago.
[05:03] <wgrant> Well, a modified version of DSA's sbuild-from-five-years-ago's algorithm.
[05:04] <micahg> wgrant: what options do I need?
[05:04] <wgrant> I haven't used pbuilder in a long time.
[05:04] <wgrant> I'm not sure if it has anything comparable.
[05:04] <wgrant> You could try uploading the other option to a PPA.
[05:04] <micahg> wgrant: a better idea :), thanks
[05:07] <lifeless> I can has sponsor ?
[05:07] <lifeless> https://code.edge.launchpad.net/~lifeless/ubuntu/maverick/pyrex/fixdepends/+merge/27667
[05:08] <lifeless> just a drive by, its trivial, and I'm about to forget it now ;)
[05:10] <ScottK> lifeless: I'd do it if you'd give me a .dsc.
[05:11] <lifeless> ScottK: what makes a dsc better for you?
[05:11] <ScottK> dget foo.dsc gets me what I need without having to remember any UDD stuff I can never remember
[05:15] <lifeless> if dget supported the url I pasted above, would you be happy?
[05:15] <lifeless> (note that bzr does - bzr branch https://code.edge.launchpad.net/~lifeless/ubuntu/maverick/pyrex/fixdepends will get effectively the same thing a dsc would)
[05:17] <lifeless> ScottK: ^
[05:19] <ScottK> Probably, although the answer is slightly more complex as I usually apt-get source package first, then get the proposed package so I have them to diff and I know I have the tarball with the correct md5sum from the archive.
[05:20] <ScottK> Obviously the diff is provided through the web U/I in this case.
[05:20] <lifeless> ScottK: for reference, the same workflow in bzr is:
[05:20] <lifeless> bzr branch lp:ubuntu/pyrex; cd pyrex
[05:20] <ScottK> (and presumably I could bzr diff too, but that would require me to think)
[05:20] <lifeless> bzr merge https://code.edge.launchpad.net/~lifeless/ubuntu/maverick/pyrex/fixdepends
[05:21] <lifeless> I'd like to have this expressed in a CLI that you find easy to use
[05:21] <ScottK> It's not at all clear from that URL, pulling the branch would get me a Debian format package.
[05:22] <lifeless> ScottK: anything with /~person/ubuntu/... in the url gets you the debian packaging
[05:23] <lifeless> unless folk are being silly, and if they are its up to us to show them where they can put there upstream branches; but you have to try pretty hard to accidentally put upstream source in the Ubuntu namespace
[05:25] <ScottK> lifeless: What that branch doesn't get me is pyrex_0.9.8.5.orig.tar.gz
[05:25] <lifeless> ScottK: bzr bd will make that on the fly
[05:25] <ScottK> I need that from the archive if I'm going to have something up upload.
[05:25] <lifeless> bzr bd -- -S
[05:26] <lifeless> pristine-tar at work
[05:26] <ScottK> Right, so the more fundamental answer to your question is that the branch is not as good as a .dsc until all the UDD stuff is easy enough to be usable for the casual user.
[05:27] <lifeless> ScottK: the question is though, is it? Certainly with your deep experience of dsc-based-workflow, they are not comparable. But for someone with no particular experience at all, I'm not sure which is easier.
[05:28] <ScottK> For someone with a deep investment in bzr stuff, the UDD stuff is probably easier.
[05:28] <lifeless> ScottK: I think its totally fair to say that udd isn't as nice as .dsc's up until new users find udd easier; I'm not sure that comparing 6 or 10 years knowledge of one toolchain with a new one you haven't learnt yet is entirely effective
[05:28] <ScottK> It depends on the case for comparing.
[05:29] <ScottK> In this case you asked to get sponsored and so the fact that you asked in a way that makes it harder for me to help you is, IMO, entirely fair.
[05:29] <lifeless> anyhow, even if udd was totally easier than dscs across the board, we can still make it easier.
[05:30] <ScottK> The other point is that UDD stuff is Ubuntu specific, so if I'm going to move to it, it needs to have enough advantage to be worth me dealing with two workflows.  One for Debian and one for Ubuntu.
[05:30] <ScottK> Obviously for people who only work in Ubuntu, that's not an issue.
[05:31] <ScottK> lifeless: What is bzr bd short for?  I apparently don't have something installed.
[05:32] <lifeless> bzr-builddeb
[05:32] <lifeless> there is a bd-do
[05:32] <lifeless> or bzr builddeb
[05:32] <lifeless> phone just rang, bbiab
[05:40] <ScottK> lifeless: What release are we on?
[05:45] <lifeless> maverick
[05:45] <lifeless> oh damn, lol - sorry
[05:45] <ScottK> No problem.
[05:45] <lifeless> thanks for sponsoring it
[05:46] <ScottK> FWIW, I think the bzr builddeb interface needs to be much closer to the dpkg-buildpackage interface.
[05:46] <ScottK> (There is a bug I filed on this)
[05:47] <ScottK> I think the bit about before -- you're talking to bzr builddep and after the -- you're talking to dpkg-buildpackage business is full of fail.
[05:54] <lifeless> yeah
[05:54] <lifeless> its a bit awkward
[05:54] <lifeless> bzr builddeb should do a small frontend perhaps
[05:55] <slangasek> hmm; I find it better than any of the commandline interfaces to date for VCS dpkg-buildpackage wrappers
[05:55] <lifeless> bzr-buildpackage, which can do the munging to bzr builddeb -- -S etc for you
[05:55] <slangasek> e.g., svn-buildpackage
[05:56] <ScottK> slangasek: For me bzr builddeb isn't competing with the other VCS wrappers, so that's interesting, but not germane.
[05:56] <micahg> wgrant: no go: http://launchpadlibrarian.net/50412899/buildlog_ubuntu-lucid-i386.chromium-browser_5.0.375.70~r48679-0ubuntu4~ppa1_MANUALDEPWAIT.txt.gz
[05:56] <slangasek> er, what's it competing with then?
[05:56] <ScottK> dpkg-buildpackage
[05:56] <ScottK> Or debuild
[05:56] <slangasek> for completely VCSless package builds, then?
[05:57] <ScottK> Yes.
[05:57] <ScottK> "The old fashioned way"
[05:58] <wgrant> micahg: That's, um, interesting.
[05:58] <wgrant> There's something special here.
[05:58] <wgrant> It normally works.
[05:58] <micahg> wgrant: I filed a bug :)
[05:58] <wgrant> I saw.
[05:58] <wgrant> But I'll probably be the one to triage it...
[05:58] <micahg> wgrant: k, let me know if I can do anything to help
[05:59] <ScottK> slangasek: If UDD/No more source packages is going to get traction, IMO the tools need to be at worst no more complex/confusing that what they replace.
[06:03] <slangasek> ScottK: I think UDD is sufficiently more powerful that it pays for a bit more complexity.  That doesn't mean it shouldn't be as simple as possible, of course
[06:04] <ScottK> slangasek: I think that's true for full time developers.  For people who use the tools more occasionally, it's much less so.
[06:12] <RAOF> Could I get someone to accept the Lucid task on bug #563100?  This has a small, upstream patch for a serious usability problem with some dual-screen setups.
[06:14] <ScottK> RAOF: done.
[06:41] <dholbach> good morning
[06:43] <RAOF> ScottK: Thanks muchly!
[07:55] <pitti> Good morning
[07:56] <ddecator> morning pitti
[09:36] <james_w> ScottK: fwiw I've been working on your bug, it's just a pain as the debuild/dpkg-buildpackage interface is so arcane
[09:36] <james_w> I agree with the principle though, so I'll get there
[09:58] <tseliot> cjwatson: can you approve my upload of xorg-server in lucid-proposed, please? (LP: #563100)
[10:11]  * maxb wonders why the ubuntu-mozilla-security PPA is building langpacks
[10:20] <pitti> maxb: it has a major new ffox version and thus also needs the new ffox translations
[10:21] <maxb> aha! :-)
[10:24] <asac> i remember vaguely that we had some magic that replaces duplicated files in /usr/share/doc or something with sym links to safe space. does that ring a bell? is that just on CD or are we doing that in some package helper for all packages?
[10:24] <cjwatson> it's only in cdbs
[10:25] <asac> ah
[10:26] <seb128> buxy, hi
[10:26] <seb128> buxy, I've opened bug #595008 and assigned it to our desktop team
[10:28] <cjwatson> tseliot: done
[10:33] <Laney> Does the SRU team need more manpower? Stuff seems to be stalling in the queue
[10:33] <cjwatson> yes
[10:33] <cjwatson> pitti is off doing other things this cycle and it shows
[10:33] <pitti> well, I still do some SRU bits, but I can only do so much
[10:37] <tseliot> cjwatson: thanks a lot
[10:50] <ScottK> james_w: Thanks.  I can understand it's not easy.
[10:51] <james_w> ScottK: tedious rather than tough. Explaining that "-s can take one of a d or n" when building a source package, or other things when building a binary, and explaining what the letters mean takes time.
[10:51] <Laney> cjwatson: Perhaps you should call for one or two more members on u-d@?
[10:52] <james_w> ScottK: I'd like to provide a good interface for those that haven't got years of experience either.
[11:02] <buxy> seb128: thanks
[11:14] <didrocks> cjwatson: I have also three SRU waiting for being accepted (f-spot, empathy, quickly), when you get some time to approve them…
[11:29] <ScottK> james_w: Also reasonable.
[12:26] <siretart> is someone already working on getting libvpx promoted to main?
[12:27] <siretart> I've just uploaded ffmpeg 0.6 to maverick, and I think it would be a real shame to miss VP8 support in main.
[12:30] <seb128> siretart, I don't think so no
[12:30] <seb128> siretart, you are welcome to write a mir for it though
[12:31] <seb128> cjwatson, hey, just pointing bug #595008 in case you are interested to subscribe, it might lead to debhelper ubuntu diffs and I think you spoke against doing that before
[12:31] <siretart> seb128: I've already spent more time than I actually should have to get 0.6 released upstream and packaged, so I'd really appreciate if someone could pick that up. otherwise I'd see to find some time to do so this week
[12:31] <cjwatson> joeyh tends to have a go at us when we do anything substantial.  please consult explicitly with him
[12:31] <siretart> cjwatson: small ping on the libfaac issue?
[12:31] <cjwatson> if it's done with his involvement and consent then I don't need to worry
[12:32] <cjwatson> siretart: you can ping, but I have no time at the moment for it, sorry :-(
[12:32] <siretart> ok
[12:32] <cjwatson> it's still somewhere on my list
[12:32] <siretart> no problem, just wanted to check
[12:32] <seb128> cjwatson, ok, buxy is sort of helping to reach something which work fore debian and us there so I guess we should stay on track, I was just pointing it in case you were interested by the changes or commenting
[12:32] <cjwatson> surely file a Debian bug
[12:33] <seb128> cjwatson, thanks
[12:33] <cjwatson> the only thing I'm worried about is stripping upstream changelogs for *everything*; that seems overkill and I hope we can come up with something better than that
[12:33] <seb128> siretart, ok, I will see if we can find somebody interested, I first want to debug why totem is not able to play lot of formats starting with avi in maverick
[12:34] <seb128> cjwatson, right...
[12:35] <siretart> seb128: just a guess in the blue, try rebuilding gst-ffmpeg against the (new) system ffmpeg 0.6, or against it's internal ffmpeg copy
[12:36] <seb128> siretart, ok, will do, thanks
[12:56] <SpamapS> james_w: ping
[12:57] <james_w> hi SpamapS
[12:58] <james_w> how's it going?
[12:58] <SpamapS> james_w: quite well thanks. :) so.. libmemcached2
[12:59] <SpamapS> james_w: I'm not sure if there's been a discussion that I missed out on regarding libmemcached ... but this is pretty important for one of my alpha2 specs.
[12:59] <SpamapS> <-- clint-fewbar  ;)
[12:59] <james_w> SpamapS: no discussion, just standard practice
[13:00] <james_w> libmemcached2 is "obsolete", not built from any source package any more, and so a maintainence pain. We try to have everything use the same version of a library by release
[13:00] <SpamapS> james_w: Right.. long term we want to stamp it out and kill it.. but the API was in absolute upheaval during 2009 and has only stabilized the last 6 months.. many upstreams haven't had time or even reason to update to 0.40's massively incompatible API
[13:01] <james_w> if something needs an old SONAME, and can't be ported then an acceptable interim solution is to reupload the old source with a new name to provide the old SONAME.
[13:01] <james_w> it's preferred to port everything though.
[13:01] <SpamapS> yes, at issue is the language bindings..
[13:02] <SpamapS> its easy to port gearman-job-server.. I will probably do that myself as I've contributed code to it in the past.
[13:02] <SpamapS> but the perl bindings, for instance, just don't implement any of the 40+ new functions and implement the old ones dead wrong.. its going to take time. :-/
[13:03] <SpamapS> also we can at least draw a line in the sand and say *only* v0.31 will be used, since it is in lucid..
[13:04] <SpamapS> and its probably reasonable to suggest that it will be dropped after 11.04
[13:04] <SpamapS> james_w: ok so I think I understand. :)
[13:05] <james_w> SpamapS: good :-)
[13:05] <james_w> SpamapS: do you have any idea if Replaces should be used?
[13:05] <SpamapS> james_w: not sure if you saw my "please fork" bug... I've been working with Monty Taylor on it.
[13:06] <james_w> SpamapS: I haven't, bug against what?
[13:06] <SpamapS> james_w: libmemcached
[13:06] <SpamapS> james_w: its just a bug to do what you're talking about.. upload the old version
[13:06] <james_w> SpamapS: great, thanks for your efforts
[13:07] <SpamapS> james_w: I figured Replaces makes more sense than Conflicts as it will eventually lead to the removal without automatic removal... but I do like the idea that a simpler control file could be used w/o replaces all over the place.
[13:09] <apw> pitti, has somethign changes with apport such that ubuntu-bug alsa-driver now reports no such package even though there is such a package in the archive?
[13:09] <SpamapS> james_w: libmemcachedutil0 would need it as they do have files that are the same, and its ok for the new version to replace the old one.
[13:09] <james_w> SpamapS: well, you don't want removal :-)
[13:10] <james_w> SpamapS: yes, that's a case for Conflicts/Replaces, but if they are co-installable and you want both to be installed then I think just removing Conflicts is enough
[13:11] <SpamapS> james_w: right, I'll give it another look and see if we can't make the control file a bit leaner. :)
[13:11] <SpamapS> james_w: thanks!
[13:11] <james_w> SpamapS: great, thanks
[13:43] <pitti> apw: alsa-driver doesn't exist
[13:43] <pitti> apw: ubuntu-bug works with binary packages, not source packages
[13:45] <apw> pitti, so what do the package_hooks for source_* do ?
[13:47] <pitti> apw: they apply to any binary of that source
[13:47] <apw> pitti, ahh ok
[13:47] <apw> i must have missreembered
[14:19] <lianj_> hello, where should i report a typo of the get-ubuntu/download website?
[14:20] <jpds> lianj_: launchpad.net/ubuntu-website-content/+filebug
[14:20] <dholbach> lianj_: https://launchpad.net/ubuntu-website/+filebug
[14:20] <dholbach> oh, sorry, maybe jpds is right
[14:21] <lianj_> nice thx! the mac's "iso to usb stick cmd help-text is wrong"..
[14:26] <lianj_> can someone logged in to launchpad please report this?  i only care because i told someone to install ubuntu and follow the instruction on your site, now he still calls me ;)
[14:28] <lianj_> its the hdiutil command of the mac help on get-ubuntu/download. it must be "hdiutil convert -format UDRW" instead of "hdiutil convert-format UDRW"
[14:29] <lianj_> its tiny but beginners might have a hard time to figure it out.. :)
[14:30] <jdstrand> dholbach: hey, how does one use harvest these days (wiki page is fine)? I go to http://daniel.holba.ch/harvest/ and it tells me it is offline
[14:31] <lianj_> bye
[14:35] <dholbach> jdstrand: it's offline, we're working very hard to get the new version online
[14:37] <jdstrand> dholbach: k, thanks
[14:38] <dholbach> jdstrand: do you need the fedora patch list?
[14:39] <jdstrand> dholbach: yes, for libvirt
[14:55] <pitti> jdstrand: http://cvs.fedoraproject.org/viewvc/devel/libvirt/ FYI
[14:55] <pitti> looks like they don't have any?
[15:13]  * Daviey *sobs*
[15:14]  * dholbach hugs Daviey
[15:14] <Daviey> \o/
[15:48] <jdstrand> pitti: yeah, I see that. guess I am on my own then :)
[15:48] <jdstrand> pitti: thanks
[16:23] <hrw> hi
[16:55] <Keybuk> oh, right, something wants to read a file off disk ... so now Linux has to slow to a crawl and all my apps have to go B&W
[16:55] <Keybuk> *sigh*
[17:01] <Keybuk> most interestingly, it's not just reading off disk - reading from NFS has the exact same effect on the system
[17:05] <tseliot> hardware failure?
[17:05] <apw> Keybuk, which kernel is that ?
[17:06] <Keybuk> apw: the Linux kernel ;-)
[17:07] <Keybuk> I've never yet encountered a Linux kernel that doesn't behave this way
[17:07] <apw> Keybuk, i think i'll ignore you
[17:07] <apw> :)
[17:07] <Keybuk> all 2.6 versions do
[17:07] <apw> Keybuk, think i've found that bug with init=
[17:07] <apw> very subtle ... just about to test ... if it works i'll get you and updated kernel
[17:07] <Keybuk> apw: kk, what was it?
[17:08] <apw> a subtlty with left and right of an &&, ie no longer executing code for obselete parameters
[17:08] <Keybuk> Don't feel too bad though, empirical testing suggests that Mac OS X's kernel suffers from the exact same problem
[17:08] <apw> which init= is one of
[17:08] <Keybuk> (just Google for "mdworker" to see)
[17:08] <apw> heh nice
[17:08] <Keybuk> and Windows' kernel can't move the mouse and multi-task, let alone do I/O :p
[17:09] <apw> heheh its still a bit shit
[17:09] <Chipzz> Keybuk: I've heard great things about this thing called Windows... ;P
[17:09]  * Chipzz runs
[17:09] <apw> Chipzz, thats called marketing
[17:09] <Keybuk> apw: I assume that it's something to do with all I/O calls still being fundamentally blocking - and I/O being prioritised highly
[17:10] <apw> Keybuk, there is some stuff about cfq being utterly broken since 2.6.27 which isn't helping
[17:12] <ogra_cmpc> Keybuk, do you have any idea why ureadahead and plymouthd would OOM on boot ?
[17:12] <ogra_cmpc> (i also have seen it for ureadahead only)
[17:14] <ion> Souldn’t /etc/init/procps.conf call sysctl with -e? procps postinst failed while i happened to be running an older kernel that didn’t have one of the variables, kernel.ptrace_scope i think.
[17:14] <Keybuk> ogra_cmpc: the kernel likes to pick on ureadahead
[17:15] <ogra_cmpc> hmm, k
[17:15]  * cjwatson wonders if ureadahead should be oom_adjusted, or if that would just result in real unkillable out-of-memory sometimes
[17:16] <Keybuk> cjwatson: dunno; in theory the memory is shared between apps
[17:16] <Keybuk> ureadahead will only open a file that was read in during boot
[17:16] <Keybuk> though that can result it in loading files which have since been closed
[17:16] <Keybuk> and you don't want the kernel OOM killing something else
[17:16] <Keybuk> if anything, ureadahead should be the *first* choice of OOM
[17:18] <cjwatson> mm, true
[17:18] <cjwatson> maybe we should just hide the evidence if that happens
[17:30] <mathiaz> cjwatson: hi
[17:30] <mathiaz> cjwatson: I was wondering how the ubuntu-server package set was generated?
[17:30] <mathiaz> cjwatson: is it generated from the seeds?
[17:30] <mathiaz> cjwatson: or is there something else involved in the selection of packages to be included there?
[17:33] <cjwatson> mathiaz: yes, it's from the expansion of these seeds: platform/supported-misc-servers platform/supported-server ubuntu/dns-server ubuntu/lamp-server ubuntu/openssh-server ubuntu/print-server ubuntu/samba-server ubuntu/postgresql-server ubuntu/mail-server ubuntu/tomcat-server ubuntu/virt-host ubuntu/eucalyptus-cloud ubuntu/eucalyptus-walrus ubuntu/eucalyptus-cluster ubuntu/eucalyptus-storage ubuntu/eucalyptus-simple-cluster ...
[17:33] <cjwatson> ... ubuntu/eucalyptus-node ubuntu/server ubuntu/server-ship ubuntu/uec
[17:34] <cjwatson> minus whatever's in "core", below it
[17:34] <mathiaz> cjwatson: ok - so to add a package to the package set it just need to be added to one of the seed?
[17:34] <mathiaz> cjwatson: I was working on the ubuntu-server package and noticed that apache2 (for ex) wasn't included
[17:34] <mathiaz> cjwatson: yet apache2 is in server-ship
[17:35] <mathiaz> cjwatson: or lamp-server
[17:44] <cjwatson> mathiaz: apache2 is (correctly) in core
[17:45] <mathiaz> cjwatson: would it make sense to have *also* included in ubuntu-server?
[17:45] <cjwatson> actually wait, let me check that
[17:45] <cjwatson> no, it would not.  packages that are in core are never in other sets
[17:45] <cjwatson> that's a fixed rule, much like packages that are in main aren't also in universe
[17:45] <mathiaz> cjwatson: what's the reason for including in the core set then?
[17:46] <cjwatson> it's hideously deep in everything's build-dependency tree
[17:46] <cjwatson> I'm just trying to trace it
[17:47] <mathiaz> cjwatson: that would also explain why mysql is not in the ubuntu-server package set
[17:47] <mathiaz> cjwatson: given that a lot of packages in core are linked against libmysqlclient
[17:48] <cjwatson> one path is apache2 <- subversion <- tcltk-defaults <- xapian-bindings <- apt-xapian-index <- ...
[17:48] <cjwatson> yes - the design is that if you get upload access to ubuntu-server then you shouldn't be able to cause serious damage to things other than server
[17:48]  * mathiaz nods
[17:49] <cjwatson> and people good enough to upload the stuff that's way down in build-dependency webs should probably be core-devs anyway
[17:49] <mathiaz> cjwatson: is core self-contained?
[17:49] <cjwatson> yes
[17:50] <mathiaz> cjwatson: so core-dev isn't going away with the archive reorg?
[17:50] <cjwatson> no
[17:50] <mathiaz> cjwatson: core-dev will have upload privileges to core?
[17:50] <cjwatson> yes
[17:50] <cjwatson> s/will have/does/
[17:50] <cjwatson> well, we did make some explicit exceptions for certain core desktop packages because the people who were in practice maintaining those weren't core-dev and it seemed to make better sense that way, e.g. kdebase -> kubuntu
[17:51] <mathiaz> cjwatson: ok - there are always exception
[17:51] <mathiaz> cjwatson: anyway - thanks for the explanation
[17:51] <cjwatson> we can consider exceptions for server in some cases, but I think I would have to ask that there should be a history of people who aren't core-dev but are in ubuntu-server competently maintaining the packages in question
[17:51] <mathiaz> cjwatson: oh - where/how did you track the apache2 dependency?
[17:52] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.maverick/rdepends/apache2/
[17:52] <cjwatson> plus
[17:52] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.maverick/boot.build-depends (one file where I noticed apache2 showing up)
[17:53] <mathiaz> cjwatson: ok - where is the mapping of ubuntu-server package set <-> list of seed defined?
[17:54] <cjwatson> in code you probably can't see, sorry
[17:54] <cjwatson> I need to push it somewhere sensible
[17:55] <mathiaz> cjwatson: ok - thanks for the help :)
[17:55] <cjwatson> you might find it on chinstrap:~cjwatson/packageset/
[17:55] <cjwatson> (bzr branch)
[17:55] <cjwatson> try not to be too violently ill, the intent was always to disassemble that and move the bits somewhere else
[17:56] <gumis> I need invite to demonoid.com
[17:56] <Pici> gumis: That is not on-topic for either this or any Ubuntu channel.
[17:56] <cjwatson> gumis: you are off-topic for this channel
[18:00] <mathiaz> cjwatson: while upgrading grub-pc on maverick I get a prompt about grub not being installed on any hard drive (or something like that)
[18:00] <ogra> omg, the merge from hell ...
[18:00] <ogra> cjwatson, wow how long did initramfs-tools take you ? :)
[18:01] <mathiaz> cjwatson: afterward while trying to upgrade linux-virtual I ran into that error: http://paste.ubuntu.com/450674/
[18:01] <cjwatson> mathiaz: second one being fixed at the moment
[18:01] <mathiaz> cjwatson: ok
[18:02] <cjwatson> mathiaz: the previous one isn't new, it's been around in lucid and I haven't dared to change the code yet, but I'll be rewriting all of that :-/
[18:02] <cjwatson> ogra: about two days, on and off
[18:02] <mathiaz> cjwatson: ok - selecting no wasn't working
[18:02] <mathiaz> cjwatson: so I had to select yes (ie not install grub) to move on
[18:02] <cjwatson> mathiaz: right, that's one of the known problems
[18:02] <mathiaz> cjwatson: great - I won't report any bug then
[18:03] <cjwatson> the loop logic is wrong, it incorporates upgrade logic each time round which fails after the first time
[18:03] <cjwatson> make sure that, ultimately, you've run grub-install somewhere.  grub-pc/install_devices shouldn't be blank, unless you have a really special case
[18:05] <mathiaz> cjwatson: right - the system is a vm and was already running before (ie grub was installed)
[18:05] <cjwatson> mathiaz: you can get past the second error by applying http://paste.ubuntu.com/450678/ to /usr/sbin/grub-mkconfig
[18:06] <cjwatson> mathiaz: that doesn't follow - the interface between grub2's core and its configuration file is not yet stable, so you have to configure things such that grub-install is run on each upgrade
[18:06] <mathiaz> cjwatson: oh ok
[18:06] <cjwatson> mathiaz: otherwise, you are practically guaranteed to have very confusing problems sooner or later, which won't be fixable any other way than running grub-install, so you might as welll
[18:06] <cjwatson> *well
[18:07] <cjwatson> it's suboptimal but so are all the alternatives
[18:09] <mathiaz> cjwatson: great - applied the patch above - and the linux-virtual upgrade proceeded correctly
[18:10] <mathiaz> cjwatson: and I ran grub-install manually afterwards
[18:21] <cjwatson> mathiaz: ok, I suggest also running   dpkg-reconfigure grub-pc   to get the auto-install configuration set up properly
[18:26] <cjwatson> ogasawara: heads-up on bug 595178, you're probably going to see a few dups of that while my fix percolates through the buildds
[18:27] <ogasawara> cjwatson: ack, thanks
[18:27] <cjwatson> the "Invalid parameter, 2.6.35-2-generic" bit in the dpkg terminal log is the relevant one
[18:27] <ogasawara> JFo: ^^ fyi
[18:27] <cjwatson> upstream patch that snuck in without my noticing
[18:29] <smoser> Riddell, if your around, could you review ebsmount 0.92 upload ?
[18:29] <Riddell> smoser: k
[18:30] <smoser> thank you.
[18:39] <apw> can anyone tell me what update-manager uses under the covers to download things?  it seems to be avoiding the apt proxy configuration
[18:41] <slangasek> apw: it uses python-apt; apt proxy configuration is a known headache; there are specs about this in the past couple of cycles
[18:42] <apw> slangasek, hrm, another reason to avoid it ... and there i was trying to be a real user
[18:42] <slangasek> apw: there may already be a known solution, I'm not sure
[18:42] <slangasek> I have no proxy
[18:43]  * apw uses an apt-cacher ... saves me hours
[18:45] <slangasek> I just have a local mirror :)
[18:46] <apw> slangasek, thats just sooo expensive to maintain compaired to the ammount of it i need
[18:52] <apw> Keybuk, http://people.canonical.com/~apw/init-all-params-maverick/  <-- replacement kernels are uploading to there as we speak, should be about another 10 mins before you have the i386 kernel
[18:53] <Keybuk> okies thanks
[19:29] <debfx> kirkland: hi, could you please have a look at this qemu-kvm patch for the upstart job: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/292588/comments/40
[19:34] <BlackZ> debfx: I think the channel #ubuntu-reviews would be the most appropiate for the patch review
[20:21] <SpamapS> get-orig-source did not create pylibmc_1.1.1.orig.tar.lzma
[20:21] <SpamapS> anybody familiar with bzr-buildpackage know why its looking for .tar.lzma?!
[20:26] <slangasek> SpamapS: it doesn't normally do that.  Is there some reference to lzma compression under debian/source?
[20:28] <SpamapS> slangasek: this particular package has no source directory
[20:32] <slangasek> SpamapS: then it sounds like a bug - but not one that I see with the bzr-builddeb package in the archive
[20:34] <SpamapS> this is on 2.4.2, running on maverick
[20:50] <ari-tczew> when is planning the next sync-work by archive admins?
[21:02] <seb128> ari-tczew, there is no schedule for this, next time an archive admin has a free slot to do it usually
[21:02] <ari-tczew> aha ok
[21:03] <seb128> ari-tczew, syncs are done every few days usually
[21:03] <seb128> is there anything you specifically need?
[21:05] <ari-tczew> seb128: not specifically, just wonder of using syncpackage by sponsors on have got sync-in-launchpad. quick response!
[21:49] <mathiaz> bdmurray: is there a way to subscribe a team to a source package via the API?
[21:50] <ajmitch> mathiaz: addBugSubscription should accept a team, I think
[21:51] <mathiaz> ajmitch: and how do I get the Launchpad Structure from a source package?
[21:52] <ajmitch> it ought to have it, let me tinker for a minute & see if I can do it
[21:52] <mathiaz> ajmitch: oh you're right
[21:53] <mathiaz> ajmitch: there is an addBugSubscription on a src package object
[21:53] <cjwatson> based on Debian bugs, latest grub2 in maverick may be broken if you have root on LVM
[21:53] <cjwatson> so just a warning ...
[21:53] <cjwatson> have started investigation but it will take a while
[21:53] <ajmitch> mathiaz: hello.addBugSubscription( subscriber=launchpad.me )
[21:53] <ajmitch> where 'hello' is a source package, it seems to have worked for me
[21:54] <mathiaz> ajmitch: right - now do I have to check if the team is already subscribed to the package?
[21:54] <mathiaz> ajmitch: it seems that this is not possible yet (as we've already discussed something similar)
[21:54] <ajmitch> I don't think so, it doesn't fail if I run it again
[21:56] <mathiaz> ajmitch: what are the getSubscription(s) methods supposed to doÉ
[21:56] <mathiaz> ajmitch: ?
[21:56] <mathiaz> ajmitch: calling them doesn't return anything
[21:56] <mathiaz> ajmitch: I would have hoped it would return the list of people subscribed to bugs for a package)
[21:58] <ajmitch> it returns the subscription, you can get the subscriber property from that it seems
[21:58] <mathiaz> ajmitch: yop
[21:59] <SpamapS> mathiaz: hey, with needs-packaging bugs.. do I still need to submit debdiffs or can I just link my branch containing the initial release?
[21:59] <mathiaz> SpamapS: hm - good question
[21:59] <mathiaz> SpamapS: I would link it to the bug report
[22:00] <mathiaz> SpamapS: it should get linked automatically actually
[22:00] <mathiaz> SpamapS: if you're refering to the LP bug number in the debian changelog in your bzr branch
[22:00] <mathiaz> SpamapS: and push your branch to LP
[22:00] <mathiaz> SpamapS: so it's equivalent to a debdiff
[22:00] <mathiaz> SpamapS: unfortunately LP doesn't support (yet?) commenting on bzr branches in a similar way to merge proposal
[22:01] <mathiaz> SpamapS: which what I'd like to really do in that use case
[22:01] <mathiaz> SpamapS: so for the time being I'd use the bug to conduct the review
[22:21] <kirkland> cjwatson: hi
[22:21] <kirkland> cjwatson: okay, i am able to run germinate on the uec-live seed I created
[22:21] <kirkland> cjwatson: i think I'm at a point where I'd like to try building an ISO from it and see what happens
[22:22] <kirkland> cjwatson: i've pushed it to lp:~kirkland/ubuntu-seeds/ubuntu.maverick.live-uec
[22:23] <kirkland> cjwatson: perhaps you can review, and tell me how to get a trial ISO built next
[22:58] <achiang> RAOF: ping