[00:00] <barry> ScottK: gotcha (i'm still using bzr, but the branch hasn't been updated yet, which is why i asked).  i may not get to it until tomorrow
[00:00] <SpamapS> ScottK: err.. uhm.. there were a number of other changes too that somehow got missed there.
[00:00] <ScottK> barry: dget https://launchpad.net/ubuntu/+archive/primary/+files/cheetah_2.4.3-0ubuntu1.dsc also works.
[00:01] <ScottK> SpamapS: I just uploaded what barry gave me, so please get it sorted out with him.
[00:01] <SpamapS> We've leap-frogged the debian package
[00:01] <ScottK> Which is OK since it gets us ~OK with 2.7.
[00:01] <barry> SpamapS: we'll have to get this back into debian experimental
[00:01] <ScottK> (modulo whatever blew up the current build)
[00:02] <micahg> ScottK: barry: since you're into python, what do you think about wxwidgets in main?  python-numpy now uses python-matplotlib to generate the docs (So it FTBFS ATM), so matplotlib has several universe build deps, but wxwidgets accounts for most of them
[00:02] <SpamapS> Just minor stuff that was fixed in the debian 2.4.2.1 package
[00:03] <barry> micahg: isn't there still some controversy about python-numpy support especially w.r.t. py2.7
[00:03] <barry> er, python-numpy version
[00:03] <ScottK> barry: http://kitterman.com/kubuntu/cheetah.debc is what my build looked like.
[00:04] <ScottK> barry: re numpy/matplotlib - We ought to decide sooner rather than later if we'll split the package or promote all the depends.
[00:05] <ScottK> SpamapS: re "minor stuff" work it out with barry and I'll upload the fixed version when you both have it ready.
[00:05] <micahg> barry: idk much about the package, just happened to be browsing through FTBFS and saw this
[00:06] <micahg> barry: I think 1.5.x has support though
[00:06] <SpamapS> barry: one way to get this right is to make 2.4.3-0ubuntu2 from the 2.4.2.1-1ubuntu1 that I merged on bug 663343 (sans the pyversions limitation)
[00:07] <SpamapS> barry: and then send that back to debian for experimental.
[00:07] <barry> SpamapS: i'll take a look at that tomorrow.  unfortunately, gotta run
[00:09] <SpamapS> barry: np will throw the bug at you when its ready
[00:13] <ScottK> barry and SpamapS: The debian/watch file also needs to be updated to point at http://pypi.python.org/pypi/Cheetah/2.4.3.
[00:20] <SpamapS> ScottK: IIRC, pypi watches don't need to point to a particular version
[00:20] <ScottK> SpamapS: Yes.  We don't want to point to just the particular version, that was meant to be exemplary and not precise.
[00:23] <SpamapS> ScottK: the shebangs in /usr/bin/* for cheetah come out as /usr/bin/python2.7 .. I doubt thats intentional.
[00:23] <ScottK> Probably not.
[00:23] <SpamapS> especially since it breaks without python2.7 installed
[00:24] <ScottK> Yep.
[00:24] <SpamapS>  Depends: python (<< 2.7), python (>= 2.6), python-support (>= 0.90.0), libc6 (>= 2.2.5)
[00:25] <SpamapS> is that a bug in pysupport?
[00:27] <ScottK> Yes.  Or more correctly the change to support python2.7 as a supported version was probably incomplete.
[00:29] <SpamapS> I'm thinking that setup.py should be called in such a way where it sets the executable to /usr/bin/python, no?
[00:30] <ScottK> There's some option for that -externally-managed or so.
[00:31] <SpamapS> 		--install-platlib=/usr/lib/python$buildver/site-packages/ --prefix=/usr --no-compile -O0 --single-version-externally-managed; \
[00:33] <SpamapS> its being called that way..  but clearly didn't work. :(
[00:33] <ScottK> Sounds right, except we want to install in dist-packages
[00:33] <ScottK> Throw --install-layout=deb in there somewhere.
[00:35] <SpamapS> thats just from the build log.. :-/
[00:35] <SpamapS> guessing cdbs is doing something naughty
[00:35] <SpamapS> actually, hmm..
[00:35] <SpamapS> DEB_PYTHON_INSTALL_ARGS_ALL += --single-version-externally-managed
[00:35]  * SpamapS tries adding it right there..
[00:36] <SpamapS> crap, its right there in the rules file
[00:37] <SpamapS> there's an attempt to fix it
[00:37] <SpamapS> which looks really hacky
[00:41] <SpamapS> ScottK: --install-layout=deb doesn't do it.. but I think I have a workaround. Like barry, I'm out of time too. :-P
[00:42] <ScottK> OK.  Tomorrow then.
[02:00] <twb> hardy's ffmpeg is FTBFSing on a hardy host, with unintelligible C datatype mismatch errors.
[02:00] <twb> Where would I find Ubuntu's equivalent of buildd logs, so I can check when *ubuntu* last successfully built hardy ffmpeg?
[02:02] <ajmitch> http://launchpad.net/ubuntu/+source/ffmpeg
[02:02] <twb> Thanks.
[02:02] <ajmitch> build logs are linked in the hardy section when you expand it
[02:03] <twb> (I'm trying to build it with DEB_BUILD_OPTS=risky for a customer who wants ffmpeg with lame, but I can't even get it to build normally.)
[02:57] <GanonKiller> has easycam been developed for meerkat?
[02:58] <twb> I had no luck with an ordinary hardy VM, but I rolled a pbuilder chroot and that is building ffmpeg just fine
[02:59] <twb> I speculate that my hardy VM had an optional build dep installed, and ffmpeg's ./configure was set to enable it if found, and it doesn't actually work with that version of the build dep.
[08:09] <pitti> Good morning
[08:13] <dholbach> good morning!
[08:14] <pitti> hey dholbach
[08:15] <dholbach> hey pitti
[08:41] <dholbach> tumbleweed, what do you think about adding merge proposal info to the sponsoring overview (like in the last column of https://code.edge.launchpad.net/loco-directory/+activereviews for example)?
[08:42] <dholbach> probably best to put that info in the status column
[08:43] <tumbleweed> yeah, sounds good
[08:43] <dholbach> I'll file a bug and see what I can do about it :)
[08:47] <geser> dholbach: is the sponsoring overview page going to stay? As I hope to finally finish the splitting of code and template for it.
[08:47] <dholbach> geser, I hope that a lot of it can go into Harvest instead
[08:48] <dholbach> which uses Django
[08:50] <delan_> what's the process for getting a package accepted into the official main/universe if it's already packaged in a PPA?
[08:50] <delan_> 'i've had a look at the wiki, but that's more about the wishlist needs-packaging bugs (mine are already packaged)
[08:50] <persia> delan_, There's lots of different ways.  The basic rule is that you want to have two members of ~ubuntu-dev say it's packaged well (because we all make mistakes)
[08:51] <persia> If the initial packager isn't already a member of ~ubuntu-dev, usually the second reviewer uploads it.
[08:51] <delan_> how can I contact the team?
[08:52] <persia> There's no reliable way to contact everyone.  What kind of package is it?  Maybe one of the flavour teams would want to help.
[08:52] <delan_> one is mathtext, a simple c-based shell-like program that transforms text into various 'styles' using Unicode
[08:53] <delan_> the other is getbooru, a php-based downloader that can scrape images from a website once a profile of regexes is written
[08:55] <persia> delan_, Hrm.  Neither of those strikes me as being tightly integrated with any of the flavours.  You might ask the MOTU if one of them would review it (ask in #ubuntu-motu).  You could also upload to REVU, but I'm not sure how many people check that regularly.
[08:56] <delan_> please tell me, what is REVU?
[08:57] <delan_> ah, i see
[08:57] <delan_> https://wiki.ubuntu.com/MOTU/Packages/REVU
[08:57] <delan_> i'll probably talk to the motu first, as you said
[08:57] <delan_> thanks for that ;)
[08:58] <persia> Be aware that a large number of MOTU don't really like more packages that don't have a maintainer, and may advise you to maintain it in Debian and let Ubuntu sync it.
[08:59] <delan_> my problem with that is (i'm not sure how to fix this, though it must be simple)
[08:59] <delan_> in the debian/changelog, I could enter 'unstable' and let it build on debian
[08:59] <delan_> but if I try to upload that to a PPA, it won't work
[08:59] <delan_> it will only work with an ubuntu version as the name, maverick
[09:00] <persia> Oh, sure.  The assumption seems to be that once you get it into normal distributions, you won't need it in the PPA anymore.
[09:00] <dholbach> hey slomo
[09:01] <persia> And I doubt anyone is going to fuss too much about the changelog entry for review: most folk consider that a trivial change.
[09:01] <slomo> hi dholbach :)
[09:02] <delan_> hm, okay then.
[09:02] <delan_> brb
[09:30] <geser> pitti: can you please moderate my voting announcement mail to ubuntu-devel-announce? Thanks
[09:31] <pitti> geser: done
[09:35] <dholbach> tumbleweed, maybe you can review my ubuntu-sponsoring merge proposal? :)
[09:38] <tumbleweed> lol, /me looks
[09:38] <tumbleweed> geser: err I got a german ballot
[09:39] <dholbach> geser, 2 nominees?
[09:39] <geser> damn, why did CIVS sent out german ballots. I didn't pick any language. Or did it took by browser language.
[09:39] <geser> dholbach: yes, only 2 :(
[09:40] <dholbach> thanks geser for organising this
[09:42] <geser> tumbleweed: but you still manage to vote?
[09:42] <ebroder> geser: The site itself was English
[09:42] <tumbleweed> geser: yes, I understand enough german to see what it was, and the subject line was english.
[09:43] <ebroder> And the vote description was English. And there was only one link that could possibly have mattered
[09:43] <geser> I feared the voting page was mostly in German too
[09:44] <dholbach> geser, beware of seb128 - he marks all German mails as spam
[09:44] <tumbleweed> an option for members with private e-mail addresses is to mail launchpadusername@ubuntu.com - AFAIK that should work for almost-everyone
[09:46] <tumbleweed> dholbach: yay, looks good - I'll test it later today
[09:47] <dholbach> tumbleweed, ok, just follow up on the merge proposal and I merge it when you're happy
[09:48] <persia> tumbleweed, It doesn't: lots of folks have differences between LP username and @ubuntu.com addresses, for complicated reasons.
[09:57] <tumbleweed> hmm, I thought those were the minority (and that they tended to have their lp username, too) - I also assume some of them will loop
[10:01] <persia> tumbleweed, hard to say.  The first few hundred @ubuntu.com addresses were given out before LP integration.
[10:02] <persia> And lots of folks have changed LP names, but that doesn't automatically change @ubuntu.com alias (or didn't, for a very long time)
[11:02] <Laney> haha
[11:40] <tkamppeter> pitti, slangasek, hi
[12:33] <ScottK> ajmitch: When you upload boost, would you also please make sure to add -py27 for boost-python?
[12:39] <ScottK> pitti: I think clamav in lucid-proposed is ready to go now: https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/653738/comments/6
[12:40] <pitti> ScottK: ok, thanks
[13:33] <Eximius> yello
[13:33] <Eximius> After giving up  on #ubuntu
[13:33] <Eximius> i came here to look for hhelp
[13:33] <Eximius> anyone having probs with BCM43** drivers and ad hoc?
[13:34] <Laney> this isn't the place for support, sorry.
[13:35] <Eximius> #ubuntu doesn't have real support, rather slackers with no idea whatsoever
[13:36] <persia> You might try #ubuntu-cc (where cc is your country code) to ask in your LoCo
[13:36] <persia> Or file a question on launchpad.
[13:36] <Eximius> hmmm
[13:36] <dholbach> Eximius, dissing people who spend a lot of time helping others won't increase your chances elsewhere
[13:37] <Eximius> I'm developing a app to use BCM43** drivers for ad hoc
[13:37] <Eximius> :D
[13:37] <Eximius> I'm not dissing
[13:37] <persia> That might be #ubuntu-app-devel, but I very much doubt anyone there can help with the problem, although they may be able to help with app creation.
[13:37] <dholbach> well, "slackers with no idea whatsover" is dissing in my book
[13:38] <Eximius> rite, so "no idea whatsoever" might be a little not true
[13:38] <dholbach> ...
[13:41] <SpamapS> Is there some reason that people use cdbs now that dh 7 exists? Seems like it just confuses things. :-P
[13:42] <bilalakhtar> SpamapS: There are some reasons why people *have* to use cdbs
[13:42] <bilalakhtar> for example, in python packages
[13:42] <bilalakhtar> though dh7 can handle that
[13:42] <dholbach> SpamapS, AFAIK at least in desktop land we have a couple of extra things that cdbs just sorts out (language-packs, etc.)
[13:42] <bilalakhtar> dholbach: yes, you're right
[13:42] <SpamapS> ah
[13:42] <tumbleweed> err dh7 is much nicer for python packages
[13:42] <bilalakhtar> the gnome-*.mk files
[13:42] <SpamapS> for python modules its just confusing me
[13:42] <SpamapS> right, dh7 gets them right
[13:43] <tumbleweed> although some people use it for python+autoconf packages (which is vaguely relevant)
[13:43] <bilalakhtar> hmm, I cannot say much about python
[13:43] <tumbleweed> yeah, CDBS screws up shebangs (I must actually test my patch for that)
[13:43]  * bilalakhtar gets pinged the moment someone says 'cdbs'
[13:43] <bilalakhtar> but as for GNOME packages, there are some CDBS includes which help
[13:44] <SpamapS> tumbleweed: yeah I think thats a bug in python-distutils.mk
[13:44] <SpamapS> no?
[13:44] <tumbleweed> SpamapS: yes and no. dh7 works around it by building with /usr/bin/python last (after all the versioned ones)
[13:44] <tumbleweed> but these days setup.py can take a --executable option to force a specific shebang (in many cases)
[13:44] <dholbach> tumbleweed, replied :)
[13:45] <SpamapS> I worked around it with DEB_PYTHON_BUILD_ARGS += --executable=/usr/bin/python
[13:45] <SpamapS> but now I'm getting leftover files in /usr/lib/python2.7/site-packages
[13:45] <SpamapS> its like dh_pysupport doesn't even see them.
[13:45] <bilalakhtar> coolbhavi is also facing similar problems
[13:45] <bilalakhtar> in his mail to ubuntu-motu
[13:46] <SpamapS> ugh.. I am loathe to subscribe to yet another mailing list
[13:46] <ScottK> bilalakhtar: There aren't any reasons why people have to use CDBS.
[13:46] <geser> ScottK: do you know what needs to be changed to fix FTBFS with python 2.7 and files being installed in site-packages? need the python packaging tools need to get updated for python2.7 or the package itself?
[13:46] <SpamapS> I'm on 37 already
[13:46] <ScottK> geser: I don't, but barry was going to look into it today.
[13:47] <bilalakhtar> Does natty use python 2.7 by default rather than 2.6 ?
[13:47] <geser> ok, then I wait on barry
[13:47] <SpamapS> bilalakhtar: not yet no
[13:47] <ScottK> bilalakhtar: No.  It's an additional supported version for modules and extensions, but not default.
[13:47] <geser> bilalakhtar: but it's already part of python-dev package
[13:47] <bilalakhtar> :)
[13:47]  * ScottK hands geser an "all".
[13:48] <geser> right
[13:49] <tumbleweed> dholbach: replied
[13:49] <dholbach> tumbleweed, super
[13:50] <dholbach> tumbleweed, which vote summary page are you referring to?
[13:50] <dholbach> (just making sure I don't misunderstand :-))
[13:52] <tumbleweed> dholbach: err, +activereviews and the summary table at the top of +merge
[14:02] <highvoltage> Ubuntu 4.10 was released 6 years ago today
[14:02] <highvoltage> on week 42!
[14:02] <highvoltage> that means that 42 was built into the Ubuntu computer since the beginning.
[14:02] <ari-tczew> who maintain hall-of-fame ?
[14:02] <highvoltage> I hope the project doesn't get destroyed before it figures out the question.
[14:03] <dholbach> ari-tczew, it's slightly unmaintained, but there's a session at UDS to revive it - what's your question about it?
[14:04] <ari-tczew> dholbach: Interviews is not updated. Last interview was reffer to Rhonda.
[14:04] <dholbach> ari-tczew, ah yes
[14:06] <tkamppeter> pitti, slangasek, hi
[14:06] <pitti> hello tkamppeter
[14:07] <tkamppeter> pitti, slangasek, it is about bug 494141. It seems that the upstartification of CUPS is not enough, but also the upstart config of Samba needs to be modified.
[14:08] <tkamppeter> pitti, slangasek, and the fact that smbd re-reads the CUPS config every 750 sec seems to be wrong.
[14:09] <pitti> tkamppeter: but cups' upstart script already reloads samba
[14:10] <tkamppeter> pitti, and how do the complaiunts of the users come, like comment #32 and #34?
[14:10] <bilalakhtar> geser: You have been uploading package multiboot for quite some time. Can I go ahead with a merge?
[14:11] <pitti> tkamppeter: then perhaps reloading samba isn't sufficient? I don't know
[14:11] <chrisccoulson_> hey pitti - would you mind sponsoring a pango SRU for me please?
[14:11] <chrisccoulson_> (for bug 655707)
[14:12] <geser> bilalakhtar: I wouldn't count two uploads within 15 min "for some time" :)  but sure, you can merge it.
[14:12] <bilalakhtar> thanks
[14:16] <tkamppeter> pitti, perhaps "kill -HUP" has not the desired effect on smbd. Perhaps it needs to be like a "restart smbd" or so.
[14:16] <pitti> chrisccoulson_: the attached branch is already in natty, and I don't see a debdiff?
[14:17] <chrisccoulson_> pitti - yeah, after i pushed my change to bzr, robert did a natty upload
[14:17] <chrisccoulson_> pitti - it's rev 7 that needs to go in to maverick - do you want me to branch off that?
[14:17] <pitti> chrisccoulson_: if you could prepare a debdiff or a branch, with the necessary changelog bug ref and all that, that'd be great
[14:17] <pitti> chrisccoulson_: (sorry, working a bit "under the gun" today)
[14:17] <chrisccoulson_> pitti - ok, no problem :)
[14:18] <chrisccoulson_> i'll do that in a bit
[14:18] <pitti> . o O { and why isn't pango1.0 in the desktop set? }
[14:18] <chrisccoulson_> pitti - it might be worth backporting this specific fix also to lucid
[14:18] <chrisccoulson_> not sure why it's not in the desktop set ;)
[14:34] <DktrKranz> lool: hi! now that python2.7 is a supported version in natty, python-support needs to be aware of that (some FTBFS have been reported already). Do you plan to look at it?
[14:37] <ScottK> DktrKranz: IIRC barry was looking at it.
[14:38] <DktrKranz> ScottK: ah, good. Thanks
[14:40] <lool> ScottK: Would you think we should implement the changes I committed in Debian for Ubuntu?
[14:40] <ScottK> lool: I haven't checked the details to have an opinion.
[14:41]  * ScottK is really hoping barry is up for worrying about it.
[14:42] <lool> barry: I committed some changes to the python-support SVN to read the supported and old versions from debian_defaults; POX and Np237 weren't too sure about that; I personally think that's ok, but it might be that it causes this list to be odd at some times
[14:59] <ari-tczew> cjwatson: I'm not sure, but I'm afraid, that MoM is not updated anymore.
[15:16] <mvo> ari-tczew: yeah, it appears to be locked since 18th
[15:22] <barry> so i was looking at this message: https://lists.ubuntu.com/archives/ubuntu-motu/2010-October/006931.html and james_w and others suggested to install pkgbinarymangler to see the failure reproduced locally.  yesterday i was successfully building cheetah locally but the buildd failed.  turns out to be the exact same failures.  but the meta issue is: why isn't pkgbinarymangler a builddep for python packages since its sanity check seems
[15:22] <barry> critical (and somewhat magical)?
[15:24] <james_w> barry, we don't want to modify every package for that
[15:24] <james_w> we could e.g. make python depend on it, but then it would put the package in the default install, which we don't want
[15:24] <james_w> we could have pbuilder and other tools automatically install it in the chroot
[15:24] <mvo> ari-tczew, cjwatson: I killed the hang process, mom should recover with the next cron run
[15:25] <barry> james_w: those are downsides, for sure.  we'll probably be touching most python packages anyway to transition to dh_python2.  i suppose we could do it then, *if* that was a direction we wanted to go in
[15:26] <barry> but having pbuilder and other tools install it might be a better way to go
[15:26] <tumbleweed> pkgbinarymangler is ubuntu-only - so it can't be a bulid-dep for python packages
[15:26] <barry> tumbleweed: i see
[15:27] <tumbleweed> yeah, it should probably be installed when variant=buildd (although I know nothing aobut debootstrap)
[15:27] <barry> another thought: that particular check is appropriate for both debian and ubuntu, so maybe that check should live somewhere else?  dh_python2 or related?
[15:27] <james_w> barry, that would be good
[15:28] <tumbleweed> barry: sounds like it should be in dh_python2, yes. In fact dh_python2 should just put them in the right place - that's what it does for /usr/local/... AFAIK
[15:28] <barry> tumbleweed: yes, dh_python2 will (or should :) just put them in the right place
[15:28] <barry> so maybe it's a moot point after that transition is complete
[15:41] <ScottK> barry: There are other reasons pkgbinarymangler can cause a build to fail, so it's generally a best practice to have it installed in your build chroot (I'll confess I forgot to add it to mine after I made it for natty).
[15:43] <cyphermox> ScottK, it's the second time I see this come up today... would it make sense to have pkgbinarymangler added to extra packages that pbuilder should install to a chroot (though that would only work for ubuntu?)
[15:43] <dholbach> ari-tczew, fixed
[15:43] <ScottK> cyphermox: It only applies to Ubuntu buildds, so not necessarily.
[15:53] <Keybuk> shtylman: whoah, fast grapevine!
[15:56] <shtylman> Keybuk: your own doing... shouldn't use twitter :p
[15:56] <Keybuk> I haven't actually said anything specific on Twitter yet
[15:56] <pitti> hey Keybuk, how are you?
[15:56] <Keybuk> pitti: hey, good thanks - you?
[15:56] <pitti> Keybuk: fine -- wrapping up my last week @ oem
[15:57] <barry> ScottK: do you agree that the python check it does will not be necessary once everything's transitioned to dh_python2?  if so, then i will just add that as a recommendation to the wiki page i use to build out the chroots
[15:57] <Keybuk> pitti: looking forwards to getting back to the distro or will you miss oem?
[15:57] <jcastro> he misses distro surely!
[15:57] <barry> or, iow, it would be okay not to install it by default
[15:57] <pitti> Keybuk: little bit of both, but I'm definitively looking forward to some natty work
[15:57] <chrisccoulson_> hi kees. would appreciate your help with bug 663294 if you get some free time :)
[15:57] <shtylman> Keybuk: lets say I have good analytical skills
[15:57] <pitti> and working on stuff that *I* actually use :)
[15:57] <ogra_ac> Keybuk, question is will *you* get to the distro at some point :P
[15:57] <Keybuk> ogra_ac: hmm?
[15:57] <ogra_ac> Keybuk, youre such a rare guest recently
[15:58] <Keybuk> heh, to IRC?  I'm usually on Jabber :
[15:58] <ogra_ac> ah
[15:58] <Keybuk> IRC is full of users who want to rant at me for things I write in changelogs and stuff
[15:58] <ogra_ac> secret communication channels ;)
[15:59] <Keybuk> but mostly been coding, so IRC is kinda distracting for that
[15:59] <jcastro> Keybuk: weren't you referring to yourself in that changelog?
[15:59] <ogra_ac> yip
[15:59] <jcastro> I thought it was just some clever wordplay.
[16:00] <Keybuk> jcastro: I don't remember - it's quite probably
[16:01] <ScottK> barry: In what century do you think the transition will finish?
[16:01] <ScottK> I'd just add it to the wiki page though.
[16:01] <barry> ScottK: the same one we remove python-support and python-central in <wink>
[16:02] <ScottK> I agree with that.
[16:02] <ScottK> Although century was probably overly pessimistic.  I should have said decade.
[16:03] <barry> ScottK: given that this decade technically ends in about 2.5 months, yeah :)
[16:03] <ScottK> It won't be this one.
[16:03] <barry> no, it won't
[16:03] <barry> but i'm mildly optimistic it will be the next one :)
[16:04] <ScottK> Right, but you're the optimist in the room.
[16:04] <barry> it's a dirty job but someone's gotta do it
[16:38] <ScottK> ajmitch: Transitioning packages off of boost1.40 is now blocked on boost-python1.42 having -py27 support ...
[16:42] <pitti> cjwatson, slangasek: do you have a minute to review postgresql-common in hardy/lucid?
[16:58] <pitti> ogra_ac: please reupload alsa-utils SRU with -v to include previous SRU
[16:58] <pitti> that didn't go to -updates yet
[17:00] <ogra_ac> pitti, oh, i need to do that for every update ? ok, no prob
[17:00] <pitti> ogra_ac: only if you put another upload on top of a -proposed one
[17:00] <ogra_ac> k
[17:00] <pitti> ogra_ac: once it goes to -updates, it's not required any more
[17:00] <pitti> i. e. we always need -v<version in final or -updates>
[17:00] <ogra_ac> oki
[17:00] <ogra_ac> i never did multiple uploads to proposed before ...
[17:01] <ogra_ac> thanks
[17:01] <micahg> pitti: I think the current gnome-web-photo SRU should be accepted
[17:01] <micahg> pitti: we won't have a better fix for a couple months
[17:01] <pitti> micahg: so that one will work then?
[17:02] <pitti> the bug trail sounded like there were some doubts
[17:02] <pitti> but sure, I can accept it
[17:02] <micahg> pitti: yes, it'll work, chrisccoulson_ was just saying that they app itself should connect differently, but that type of change  seems more risky for an SRU
[17:02] <pitti> okay
[17:02] <micahg> *the
[17:02] <tseliot> pitti: if we have changes that involve the debian directory and we're dealing with a package that uses 3.0 (quilt) format, shall we modify the files in debian/ directly or shall we create a patch that does the same thing?
[17:03] <pitti> tseliot: directly, please
[17:03] <tseliot> pitti: ah, this could be the reason why quilt is giving me so many problems. Thanks
[17:15] <SpamapS> barry: good morning.. are you around? I've been working on trying to get cheetah to build and work w/ python 2.7 properly...
[17:19]  * geser guesses that every IRC ping barry gets today it about python 2.7 related FTBFS :)
[17:20] <SpamapS> haha
[17:20] <SpamapS> you reap what you sow
[17:23] <SpamapS> cheetah at least builds, but it borks things up quite a bit.
[17:23] <dholbach> can somebody moderate my mail on u-d-a?
[17:26] <geser> SpamapS: that's a common error in the build logs, I guess barry will fix the tools to cope with python2.7 too. I guess you just need to wait for that fix.
[17:26] <SpamapS> geser: Yeah, I'm hoping I can offer some help in some way.
[17:27]  * SpamapS is on an SRU/merge/backports mission in between reading blueprints.
[17:28] <kees> chrisccoulson_: sure, I'll take a look
[17:29] <chrisccoulson_> kees - thanks
[17:30] <chrisccoulson_> i'm just building mozilla-central with -fstack-protector now
[17:32] <kees> chrisccoulson_: looks like a glibc bug
[17:32]  * kees continues to read
[17:32] <chrisccoulson_> kees, OOI, what makes you think glibc?
[17:32] <zyga> mvo, around/
[17:33] <kees> chrisccoulson_: hadn't gotten far enough, just saw the top level pthread stuff.
[17:34] <chrisccoulson_> kees - ah, yeah, there's a bit more analysis below that ;)
[17:34] <kees> does firefox overload malloc somehow?
[17:34] <kees> anyway, I'll shut up until I read all the way through it :)
[17:34] <chrisccoulson_> kees - yeah, it provides it's own malloc implementation
[17:34] <chrisccoulson_> the stock glibc malloc suffers too much from fragmentation
[17:49] <Keybuk> chrisccoulson_: huh?
[17:49] <chrisccoulson_> Keybuk, was that in response to my last comment?
[17:50] <Keybuk> yes
[17:50] <Keybuk> I'm curious as to why this *matters*
[17:52] <chrisccoulson_> Keybuk, when mozilla did a lot of work to optimise the memory footprint of firefox before 3.0, they found a lot of memory was being wasted due to fragmentation, which ends up with memory not really being released back to the system
[17:53] <Keybuk> sure, but it doesn't matter
[17:53] <Keybuk> Linux assumes no process releases its memory
[17:53] <Keybuk> firefox manages to consume so much it actually hits swap
[17:53] <Keybuk> which will be unrelated to that fragmentation
[17:54] <Keybuk> sounds more like they're blaming something else for their own failure
[17:56] <kees> I do find it scary that it uses its own malloc; glibc's is actually pretty safe.
[18:00] <smoser> anyone used the python-apt ? i was hoping to use it to download and inspect archives from a different arch than the running arch.
[18:00] <smoser> but I didn't see a way to do so.
[18:10] <kees> smoser: I always use the LP API to do archive validation
[18:12] <smoser> kees, well, this particular itch was converting binary package -> source package
[18:12] <smoser> to which i was told launchpad was not capable
[18:12] <tgardner> cjwatson, whats the normal way for enabling bootstrap chroots? I have a patch to enable natty in Lucid debootstrap. Shall I upload it?
[18:12] <kees> smoser: well, that's just because multiple sources can produce a binary package
[18:13] <smoser> (other than the screen scraping that "works for me" right now) from https://launchpad.net/ubuntu/<release>/<arch>/<binpkg>
[18:13] <kees> smoser: but yeah, it's a fair point.
[18:13] <kees> open a bug! :)
[18:13] <kees> I can't search by CVEs in the API either. ;)
[18:13] <smoser> well, i supposed that is true. but i have binary package, version, and know it came from one of main  universe updates or security
[18:14] <smoser> and i can't get what i want.
[18:14] <kees> when I did the seed analysis, I'd pull down the Packages files and parse them. :(
[18:14] <smoser> yeah, which is what python-apt would do for me
[18:14] <smoser> but i dont see how i can tell it to pull from something other than arch=(uname -m)
[18:15] <smoser> just trying to re-invent as  little as i can
[18:16] <smoser> mvo, ^^ do you know if i can tell python-apt to pull cache for a different arch than current ?
[18:20] <Q-FUNK> mvo: wrt bug #587186 I wanted to ask, what did you end up checking for?
[18:33] <kees> pitti: still around? how do I get something onto the sync-from-debian-blacklist?
[18:33] <kees> I don't want python-pyftpdlib coming in unless it clears its current hurdle of WAY too many CVEs open. :)
[18:34] <pitti> kees: need to run now, sorry; any archive admin can do that
[18:35] <ScottK> tgardner: The usual way is just to backport debootstrap from the development release (or in this case from Maverick)
[18:35] <tgardner> ScottK, I have the patch developed from a previous example. I just wanted to make sure I wasn't stepping on any toes
[18:36] <ScottK> tgardner: It should be a no change backport that any Canonical archive-admin can just do.
[18:36] <kees> jdstrand: why hello. :) got a moment for a blacklist addition?
[18:40] <kees> chrisccoulson_: what happens if you turn off the malloc replacement logic?
[18:42] <kees> chrisccoulson_: you just did a test build with -fstack-protector or with -fno-stack-protector?
[18:42] <chrisccoulson_> kees - i haven't tried turning off the internal malloc, but i guess it will work
[18:43] <chrisccoulson_> i did a build with -fstack-protector, and it works fine
[18:44] <kees> how were you building where it didn't get -fstack-protector automatically?
[18:44] <jdstrand> kees: whatcha need?
[18:44] <smoser> ok. so i'm not real familiar on the process for this, but currently natty python-paramiko depends on python-crypto (>= 2.1.0-2). but 2.0.1+dfsg1-4ubuntu2 is current.
[18:44] <jdstrand> kees: and hi!
[18:45] <smoser> do i need to file a "sync from debian" request for python-crypto ?
[18:45] <kees> jdstrand: hi! :) can you blacklist python-pyftpdlib so it doesn't enter natty from Debian? It has a stack of CVEs, and I want to make sure they're addressed before we get that into Ubuntu (it's very new in Debian)
[18:45] <smoser> oh. actually i see its already done: https://bugs.launchpad.net/ubuntu/+source/python-crypto/+bug/662883
[18:46] <mvo> smoser: yes, set "apt.apt_pkg.config.set("Apt::Architecture","armel")" at the start (before you init your apt.Cache()"
[18:46] <smoser> mvo, awesome. thank you.
[18:46] <chrisccoulson_> kees - i'm just building a stock checkout from mozilla-central (make -f client.mk with a minimal set of build options in mozconfig)
[18:47] <mvo> Q-FUNK: hold on a sec, I can look for the commit diff
[18:47] <kees> chrisccoulson_: but our compiler forces -fstack-protector ...
[18:47] <mvo> smoser: you know apt.Cache(rootdir="some-dir") too, right?
[18:47] <chrisccoulson_> oh, ok. i didn't realise that
[18:47] <smoser> mvo, yeah, thats what i was using/abusing
[18:47] <kees> chrisccoulson_: perhaps it's the -fPIE -pie bits from hardening-wrapper?
[18:47] <mvo> smoser: make creating multiple "apt-roots" really easy
[18:47] <mvo> smoser: oki
[18:47] <chrisccoulson_> kees - yeah, possibly. will try with just those now
[18:47] <kees> chrisccoulson_: so, just so I understand, which builds have worked, and which have failed?
[18:48] <hicham> chrisccoulson_: you updating to xulrunner2 ?
[18:48] <chrisccoulson_> kees - building our ubuntu packaging branch with our gcc-4.5, and also debians gcc - all fail
[18:48] <chrisccoulson_> building stock mozilla-central with both gcc versions - both ok
[18:48] <kees> chrisccoulson_: okay, but a stock build worked? sounds like PIE
[18:49] <chrisccoulson_> building our packaging without DEB_BUILD_HARDENING also works with both gcc versions
[18:49] <kees> yup.
[18:49] <kees> so that means it's either PIE or BIND_NOW
[18:49] <bilalakhtar> Keybuk: Are you serious on leaving Canonical?
[18:50] <kees> chrisccoulson_: let me check something and see if you can easily eliminate BIND_NOW as a variable without doing a full recompile...
[18:50] <chrisccoulson_> kees - i'll need to do a recompile anyway, i've borked my build environment
[18:50] <kees> chrisccoulson_: hah, whoops
[18:51] <smoser> doko_, can you please re-evaluate 662883 ?
[18:51] <kees> chrisccoulson_: okay, well, leave DEB_BUILD_HARDENING=1 but add DEB_BUILD_HARDENING_PIE=0 to disable just the PIE part.
[18:51] <chrisccoulson_> kees - ok, doing that now
[18:51] <chrisccoulson_> thanks
[18:52] <kees> chrisccoulson_: and if that works, then we've isolated the problem, and can try to forward this to gcc or something.
[18:53] <hicham> what does DEB_BUILD_HARDENING_PIE do ?
[18:53] <kees> hicham: http://wiki.debian.org/Hardening#DEBBUILDHARDENINGPIE.28gcc.2BAC8-g.2B-.2B--fPIE-pie.29
[18:54] <kees> hicham: it enables relocation for the text segment of the binary
[18:54] <kees> hicham: i.e. -fPIE -pie compiler flags, like -fPIC for shared objects, but for the main binary
[18:54] <jdstrand> kees: done
[18:54] <kees> jdstrand: thanks!
[18:55] <hicham> kees: there are some text relocs in libxul.so FWIW
[18:55] <chrisccoulson_> judging by my analysis of the problem, -pie sounds like a plausible culprit ;)
[18:55] <chrisccoulson_> right, that's building now
[18:55] <kees> hicham: all of libxul.so should be relocatable (since it's a shared object and must be compiled with -fPIC)
[18:56] <chrisccoulson_> i will also do a stock mozilla-central build with -pie, which is the only combination i haven't done so far i think
[18:56] <kees> chrisccoulson_: weird that it would show up in this way. but if gcc-4.4 works but gcc-4.5 doesn't, then we should be able to show the problem to upstream
[18:56] <hicham> kees: most have been fixed ( the relocs from libvpx), but there are one or two relocs remaining from gfx/Layers code
[18:56] <kees> chrisccoulson_: injecting -fPIE -pie can be tricky, depending on how they call the linker
[18:57] <chrisccoulson_> kees - yeah, i'm running 2 stock mozilla-central builds now - 1 with DEB_BUILD_HARDENING_PIE=0 and 1 without
[18:58] <chrisccoulson_> this is where my machine begins to smoke
[18:58] <chrisccoulson_> :)
[18:58]  * chrisccoulson_ goes to find some dinner to cook on his laptop
[18:59] <hicham> kees : who maintains ff in ubuntu ?
[19:00] <kees> hicham: chrisccoulson_ IIUC :)
[19:00] <chrisccoulson_> yeah ;)
[19:00] <hicham> kees:  thanks
[19:01] <kees> hicham: ah, I may have confused the language around "relocatable text" vs "text relocation". I just just say "position independent code"
[19:01] <kees> *I should just ...
[19:03] <hicham> kees: i just wanted to know ubuntu's stand on the bundled libvpx
[19:04]  * kees tries to pick a hat to wear for a reply to that
[19:04] <chrisccoulson> what do you want to know?
[19:17] <barry> doko_: ping
[19:17] <kees> chrisccoulson: so, in your bug report, you show 0xf7ff6720 twice
[19:18] <kees> chrisccoulson: in the first instance, it has a nop and other stuff before the mov to %edi. in the second, it's been reduced to 1 instruction
[19:18] <kees> chrisccoulson: that seems mighty strange.
[19:22] <tgardner> kirkland, re: debootstrap in Lucid, ScottK says 'tgardner: It should be a no change backport that any Canonical archive-admin can just do'. Can you do that?
[19:23] <kirkland> tgardner: what is it you want to do?  put Maverick's debootstrap into lucid-backports?
[19:23] <tgardner> kirkland, yep, I need a natty schroot
[19:24] <kirkland> tgardner: and you want it in the official lucid-backports archive, rather than just putting it in a PPA, or building it locally for yourself?
[19:25] <tgardner> kirkland, yes. the kernel team  uses the schroot on a bunch of machines. Adding it to -backports is what has been done in the past
[19:25] <kirkland> tgardner: okay, let me take a look
[19:25] <smoser> i believe that we have had updates like that into -updates (not -backports) in the past
[19:26] <smoser> just for adding new release names
[19:26] <smoser> (which is all you need for debootstrap, a single 'ln -s gutsy natty')
[19:27] <tgardner> smoser, I have a patch for the Lucid debootstrap that does just that, but I wanted to make sure it was the right way before I uploaded it.
[19:27] <smoser> i swear that there was a special allowance for "release names" to be "back ported". but maybe i just dreamed that.
[19:28] <tgardner> smoser, looking at the lucid package I think thats what was done.
[19:28] <tgardner> for maverick at least
[19:29] <kirkland> tgardner: yeah, i think i'd rather that -- a small fix that adds natty
[19:29] <tgardner> kirkland, ok, I'll upload in a few minutes
[19:29] <kirkland> tgardner: cool, thanks
[19:29] <kirkland> pitti: looks like debootstrap 1.0.20ubuntu1.1 has been in lucid-propose for 9 weeks
[19:30] <kirkland> tgardner: make sure you base your update on debootstrap 1.0.20ubuntu1.1 from lucid-proposed
[19:30] <kirkland> tgardner: i'll try to get pitti to clear that one from the queue
[19:30] <kirkland> tgardner: so that your .2 can go right in
[19:31] <tgardner> kirkland, right, thats the version I started from
[19:31] <kirkland> tgardner: good
[19:32] <tgardner> kirkland, ok, uploaded
[19:35] <SpamapS> can I get somebody to take a look at bug 660990 for sponsorship? would like to ship an SRU into maverick for it.
[19:36] <kirkland> tgardner: okay, pitti has to clear out the .1 version from -proposed first
[19:44] <AnAnt> Hello, what are :: entries for in makefiles ?
[19:45] <tumbleweed> AnAnt: http://www.gnu.org/software/make/manual/make.html#Double_002dColon
[19:49] <AnAnt> tumbleweed: thanks, so that means, if I have several build:: targets in the makefile, all of them will get executed ?
[19:49] <tumbleweed> AnAnt: yes. cdbs uses that for customisation
[19:49] <AnAnt> thanks
[20:01] <barry> is someone available to review and/or sponsor bug 664068?
[20:02] <SpamapS> barry: reviewing now.. but cannot sponsor. ;)
[20:03] <SpamapS> barry: ugh, all those hard coded versions are what is driving us nuts?!
[20:03]  * SpamapS gives it a whirl
[20:05] <barry> SpamapS: yeah, but eventually it will all be better (tm)
[20:07] <SpamapS> barry: testing now w/ cheetah ;)
[20:08] <barry> SpamapS: thanks!
[20:10] <SpamapS> pitti: looks like drizzle is picking up our work! ;) http://drizzle.org/workitems/
[20:14] <chrisccoulson> kees - doing 2 parallel builds probably wasn't a good idea ;)
[20:14] <chrisccoulson> it would have been faster to do them one after the other
[20:14] <SpamapS> barry: hmm.. it did remove the site-packages dirs now.. but no pyc compilation
[20:15] <barry> SpamapS: on build?  that's actually a good thing :)  pycs are built at install time
[20:15] <SpamapS> no on install
[20:15] <barry> that's bad :(
[20:16] <SpamapS> Could be something else wonky in this system
[20:16] <Pici> 22
[20:16] <SpamapS> Pici: how'd you know my lucky number? ;)
[20:16] <Pici> SpamapS: Magic ;)
[20:17] <directhex> asac: can i talk to you regarding a mono patch you wrote for ARM?
[20:17] <SpamapS> barry: update-python-modules uses the same source for supported versions, right?
[20:23] <SpamapS> barry: even manually running 'sudo update-python-modules -f' doesn't create the pyc's for cheetah, though it did create them for others
[20:24] <barry> SpamapS: hmm.  i'm distracted with something else atm, but will get back to this asap
[20:24] <SpamapS> barry: ok, I'll post my experience to the merge proposal
[20:24] <barry> thanks!
[20:38] <chrisccoulson> kees - ok, build with DEB_BUILD_HARDENING_PIE=0 is good :)
[20:39] <chrisccoulson> just waiting for the other build to finish, just to confirm that one fails to start
[20:39] <kees> chrisccoulson: well, that's a bit scary, but okay, at least we've isolated it.
[20:39] <chrisccoulson> kees - yeah, i want to wait for the other build to finish first, because they're totally identical except for that one option
[20:39] <kees> cool
[20:41] <ajmitch> ScottK: sorry, are there other things you need me to break in boost1.42 before I upload it?
[20:42]  * ajmitch is still waiting on the laptop to resume properly before he can check it
[20:42] <doko_> smoser: well, why drop a patch, which we will introduce later again this cycle? if you want to go forward, please use dh_python2 instead of python-central
[20:42] <chrisccoulson> kees - ok, now i'm really confused. the other build works too :/
[20:43] <kees> O_o
[20:45] <smoser> doko_ will admit to not really being knowledgable about what was going on there. but the poster said the end result is the same with or without the patch that was droppd.
[20:47] <doko_> smoser: there is no guarantee that a helper will do the correct things within /usr/local, and dh_python2 warns about that too. I'll have a look at the merge if nobody wants to do it
[20:49] <smoser> well, i personally would appreciate it.  i can do it, but having my uec-images build *right now* is my main interest.  and the learning curve would be more time consuming than leaching from you
[20:49] <smoser> :)
[20:49] <chrisccoulson> kees - oh, it helps if i actually use the right gcc version.....
[20:49] <chrisccoulson> ;)
[20:49]  * chrisccoulson crawls under a bus
[20:50] <kees> chrisccoulson: oops. :P
[20:52] <chrisccoulson> i'm deeply embarassed now, i've just wasted 2 hours of my evening waiting for those to finish ;)
[20:53] <tumbleweed> doko_, smoser: I'll happily provide a merge. I just thought that if it works unmodified there's no point in having ubuntu-modifications.
[20:54] <doko_> tumbleweed: in principle, yes, but we finally want to robustify the python packaging, eliminating symlinking at install time for packages on the CD
[20:55] <tumbleweed> doko_: I'm aware of that
[20:56] <doko_> tumbleweed: so do it now, and don't touch it later again ;)
[20:56] <tumbleweed> heh, well that won't happen until 2.6 is gone, I assume
[20:59] <chrisccoulson> kees - ok, take 2 now (builds kicked off, with the correct gcc version this time)
[21:01] <kees> chrisccoulson: okay, cool.
[21:02] <tumbleweed> doko_: oh on the CD, you mean before then. Should I do a merge that also converts to dh_python2 then?
[21:04] <doko_> tumbleweed: would be appreciated, yes. just make sure that all files are still included
[21:04] <tumbleweed> sure
[21:11] <smoser> tumbleweed, doko_ thank you.
[21:29] <ScottK> ajmitch: Just adding -py27 to the versions for boost-python.
[21:32] <ajmitch> from a 10-second overview, I don't see python versions hardcoded in it at the moment
[21:35] <smoser> anyone aware of code to parse 'LP: #' bug identifiers from a string ?
[21:36] <smoser> ideally woudl support debian style bug reference also, and 'LP: #1, #2'
[21:42] <geser> somewhere in a perl module from dpkg (IIRC)
[21:46] <micahg> doko_: is the icedtea plugin going away, or did it just move somewhere?
[21:47] <doko_> micahg: split out into a separate package, so that you can take over maintenance ;)
[21:48] <micahg> doko_: heh, happy to help if I can :)
[21:58] <TommyBrunn> Hello everyone. I'm trying to find some up-to-date information on creating Gnome panel applets in Python, but I can only seem to find old, outdated and incorrect resources. Do any of you have any idea where I can find good documentation?
[22:08] <BUGabundo> guud evening
[22:09] <tuxmountain> Hi
[22:10] <tuxmountain> how are you?
[22:10] <BUGabundo> tired
[22:10] <BUGabundo> in need of a couple new eye balls
[22:11] <tuxmountain> I've a question (I don't know if it's here the best place for that but I try!)
[22:12] <tuxmountain> Why WUSB600N is totaly supported in 9.04... but not in 9.10 or 10.4...?
[22:12] <tuxmountain> With 9.04 you install ubuntu, and the wifi works
[22:13] <tuxmountain> but with 9.10... you need ndiswrappers! Why?
[22:13] <tuxmountain> It's not possible to use a old paquet for the wifi?
[22:25] <tuxmountain> /etc/modprobe.d/blacklist.conf is the file for active the old module?
[22:41] <chrisccoulson> kees - ok, confirmed it is pie now
[22:42] <chrisccoulson> i guess it would be useful for me to figure out a minimal case to reproduce it
[22:42] <kees> chrisccoulson: that would be optimal, yeah
[22:48] <lifeless> barry: here ok ?
[22:49] <lifeless> barry: is there a session about multiple versions of python libraries being supported planned for uds ?
[22:49] <barry> sure
[22:49] <lifeless> barry: I know jos said (roughly 'mmm, nice idea, no time'), but I think it would be -awesome- to get this actually moving.
[22:50] <barry> lifeless: not as such.  we have a few blueprints carried over from mav but no sessions planned.  i think we[*] are pretty much in agreement on the plan for natty
[22:50] <lifeless> barry: And I'd be delighted to be the grain of sand
[22:50] <barry> [*] ScottK, doko, myself at a minimum
[22:50] <lifeless> barry: oh, I don't mean python3.1+3.2
[22:50] <lifeless> I mean zope.appserver1.3 + zope.appserver1.4
[22:50] <barry> ah, right.  no nothing planned for that
[22:51] <lifeless> barry: I don't think that *that* has been previously specced? Or maybe its the same thing (but I don't believe so?)
[22:51] <barry> lifeless: no you're right, i misread
[22:51] <ScottK> Wasn't the zope answer "Use buildout"?
[22:51] <lifeless> ScottK: which is terribly unsatisfying
[22:51] <barry> well, the python answer is buildout|virtualenv
[22:52] <lifeless> in fact, you could use buildout + concurrent package installs
[22:52] <lifeless> but until we support it in the core, its very hard to start sending better-support patches upstream
[22:53] <barry> lifeless: if you create the blueprint/session i will definitely attend <wink>
[22:54] <lifeless> barry: I'm seeking a champion :)
[22:54] <lifeless> barry: and I figure, given your knowledge, that you're ideal!
[22:54] <barry> lifeless: i am very sympathetic, but i have so much on my plate right now ;}
[22:55] <lifeless> :(
[22:55] <barry> lifeless: i'd really love to defer this until pycon 2011 time frame.  i want to sit down with tarek and maybe the fedora guys and think about what can be pushed into the core and what must be done on the distros
[22:56] <barry> i know that sucks for you though
[22:56] <lifeless> barry: ok
[22:56] <lifeless> I doubt I'll be at pycon though
[22:57] <barry> lifeless: apol if you've already done this, but at a minimum, can you write up a wiki page about what you'd *like* to see?  something that i can show tarek and say, "hey, what can distutils2 do to help us"?
[22:57] <lifeless> barry: that mail I sent you :)
[22:57] <lifeless> I'll look at something more referencable though
[22:58] <barry> lifeless: yeah, i know.  email is so easily buried ;) (like wiki pages aren't easily forgotten)
[22:59] <barry> lifeless: that would be great.  please know i understand how important this is and as i say i'm with you.  there are other things that have to get finished by 13-nov (python 3.2's beta 1)
[22:59] <slangasek> ajmitch: brainstorming: I think a key here is going to be a client tool that keeps track of Packages files, can extract a list of updated packages from those files, and use that to decide which branches to pull from - to avoid polling 16k branches, one TCP connection at a time, when maybe only 200 branches have been updated that day
[22:59] <lifeless> slangasek: context?
[23:00] <ajmitch> keeping a local mirror of packaging branches
[23:00] <lifeless> just use the ubuntu branches rss feed
[23:00] <slangasek> lifeless: "UDD will always be slower than my local mirror until I can have UDD on my local mirror" :)
[23:00] <slangasek> where's that?
[23:00] <lifeless> looking
[23:00] <lifeless> it *should* just exist, as the project group ones etc doo
[23:01] <lifeless> but if it doesn't, I'll file a bug
[23:01] <slangasek> ok
[23:01] <slangasek> is the RSS feed over SSL?
[23:01] <ajmitch> lifeless: want me to file a bug still for LP timeout OOPS that I run across?
[23:01] <lifeless> ajmitch: god yes
[23:02] <lifeless> ajmitch: if there isn't one tagged timeout
[23:02] <lifeless> launchpad-project/+bugs?field.tag=timeout
[23:02] <ajmitch> I'm guessing that https://code.edge.launchpad.net/~ubuntu-branches must be a fairly large list
[23:02] <lifeless> ajmitch: yes
[23:02] <lifeless> but thats not wher eyou should look
[23:02] <lifeless> thats the old style
[23:03] <ajmitch> there's a bug open for it at least
[23:03] <lifeless> http://feeds.edge.launchpad.net/launchpad-project/revisions.atom is the lp project one
[23:03] <lifeless> ok, there isn't an ubuntu one
[23:03] <lifeless> I'll file the bug
[23:04] <slangasek> ok
[23:05] <slangasek> lifeless: what kind of detail will that give me?  For instance, if I want a mirror of all of main + a selection of packages from universe that interest me, will I get enough info from that RSS feed or do I need to poke at supplementary sources anyway?
[23:05] <lifeless> slangasek: no idea; you could certainly use it to decide what to inspect and use germinate rules for better control
[23:05] <lifeless> slangasek: how important is this
[23:06] <slangasek> lifeless: I think having a flexible mirroring tool for UDD is a tipping point for its wider adoption; not necessarily asking you to dedicate resources to solving it right at the moment
[23:06] <barry> do any sbuild users know how to make sbuild use an schroot session?  i have a locally built .deb that i'd like to build another package against.  i can create an schroot session and install that .deb but i can't figure out how to get sbuild to use that session when building the second package
[23:07] <barry> sbuild --schroot `cat session-id` doesn't seem to work
[23:07] <lifeless> slangasek: https://bugs.edge.launchpad.net/launchpad-code/+bug/664195
[23:08] <barry> er, --chroot `cat session-id`
[23:08] <ajmitch> slangasek: the other side of that is changing the bzr-lp plugin to prefer local repositories for fetching revisions from, so that you can still do 'bzr branch lp:foo'