[00:04] <micahg> can a DD please help this person (bug 928556)
[00:04] <ubottu> Launchpad bug 928556 in mosquitto (Ubuntu) "Package out of date - 0.15 available" [Undecided,New] https://launchpad.net/bugs/928556
[00:06]  * tumbleweed has a quick look
[00:10] <tumbleweed> not the most useful VCS branch
[00:12] <micahg> tumbleweed: was pointing to a DD as supposedly there's something to be sponsored to Debian (which would be preferred to reviewing/uploading to Ubuntu)
[00:12] <Laney> mentors has it
[00:13] <Laney> 3 sponsors in 4 revisions isn't the most helpful situation though
[00:13] <tumbleweed> well, some sponsors don't seem to encourage their sponsorees to come back
[00:14] <directhex> it's not a good situation to be a sponsor of something you don't care about
[00:14] <directhex> for one thing it's hard to adequately apply any packaging review
[00:15] <Laney> and it means the finding a sponsor cycle has to be repeated again (and again)
[00:15] <tumbleweed> yeah, first few reviews someone is *slow*
[00:15] <Laney> perhaps he did contact them
[00:15] <tumbleweed> reviews for someone
[00:15] <tumbleweed> (and yo have to get your head around the packaging)
[00:16] <tumbleweed> one of the reasons worknig in ubuntu is nice. It's all the quick and easy stuff :P
[00:16] <Laney> oojah: (since you're here :P) did you contact mt and kilian to sponsor the new mosquitto?
[00:17] <tumbleweed> micahg: did you look at the package's vcs branch?
[00:17] <micahg> no
[00:18] <tumbleweed> its cross-distro
[00:20]  * tumbleweed -> bed
[01:43] <Corey> I'm trying to use dh --with python2, but whenever I apply that, packages need a newer version of Python than is in Lucid and the package fails (2.6.6 vs the 2.6.5 that Lucid has)
[01:50] <micahg> right, you can't use that in lucid
[01:50] <micahg> take a look at I think pastebinit to see a trick
[01:51] <barry> Corey: dh_python2 is still awaiting backport to lucid: bug 788524
[01:51] <ubottu> Launchpad bug 788524 in python-defaults (Ubuntu) "backport dh_python2 to lucid (and maverick if appropriate)" [High,In progress] https://launchpad.net/bugs/788524
[01:55] <Corey> barry: Hmm. How do I sanely get my sid pbuilder chroot to build a package that properly stuffs the python stuff into /usr/lib/python2.6/dist-packages/ instead of pyshared and/or pymodules?
[01:56] <barry> Corey: i'm actually at eod.  if no one else can help you here, can you ping me tomorrow, sometime after 1400utc?
[01:57] <Corey> barry: Will do if nobody gets to me, thanks.
[02:03] <Corey> The stuff in pyshared and pymodules *works*, it's just inelegant and not how we like to do things.
=== Zhenech__ is now known as Zhenech
=== Zhenech is now known as 36DAAR2FL
[02:28] <epikvision> how long do openpgp keys take to be validated
[02:28] <epikvision> ?
[02:29] <blair> i just noticed that 12.04 packages for python modules now only provide python 2.7 modules, not both 2.6 and 2.7, who can i talk to to reverse this decision for 12.04?
[02:29] <ScottK> blair: It's not going to happen.
[02:31] <blair> ScottK, not even if i provide a good reason why ????
[02:31] <ScottK> If you've got a problem with something working with python2.7, the solution is to make it work with 2.7.
[02:31] <blair> ScottK, no, that's not the issue
[02:31] <ScottK> What's the issue/
[02:31] <ScottK> ?
[02:33] <blair> I work for Sony Imageworks and we have ~500 artists using Autodesk Maya 2013 for special effects (movies like Green Lantern) and Maya only supports Python 2.6 and won't go to 2.7 for another year
[02:33] <micahg> python2.6 is planned to be dropped from precise as soon as the final reverse dependencies are resolved
[02:34] <blair> i'm pushing to go from fedora 13 to 12.04 and one of the benefits is that ubuntu would provide 2.7 for people working outside of maya and 2.6 for people working in Maya
[02:34] <blair> it's a huge pain on our *ss to compile all python modules for an older Python release, so i was really excited to see this in ubuntu
[02:35] <blair> i think ubuntu should look at supporting an older python for commercial products like Autodesk Maya
[02:36] <blair> is it a goal of an LTS release to be an official distro for more commericial linux software packages?
[02:36] <blair> right now the whole visual effects industry is on rhel/fedora distros, so anything to help with ubuntu getting in would be helpful
[02:38] <blair> is there a mailing list i can shoot an email off to?
[02:42] <micahg> blair: AIUI, the 2.6 branch upstream is almost dead and would be very difficult to support for 5 years
[02:42] <blair> micahg, that makes sense
[02:44] <blair> if i wanted a ppa and recompile sources, what would i need to change to have the build process also make 2.6 modules?
[02:44] <micahg> blair: if you only need 1 year of support, lucid is supported until Apr 2013
[02:45] <blair> we're in the boat now on an unsupported OS (fedora 13) which is over a year old
[02:45] <blair> it takes 6-9 months to move 500 desktops to a new OS
[02:45] <micahg> blair: you'd need python-minimal I believe, but ScottK would know better
[02:46] <blair> argg, i was so excited when i saw multiple python support in oneiric and just assumed it would carry forward to precise
[02:46] <micahg> or rather the python-defaults package set up for it
[02:46] <blair> it would save to much work on our sysadmin team
[02:46] <blair> s/to much/so much/
[02:47] <micahg> blair: if it's just one piece of software that you need to support though, a PPA doesn't seem like such a bad solution
[02:48] <achiang> +1 to PPA. i think that's a pretty good solution to your specific problem
[02:48] <achiang> i bet you might even find some other crazy volunteers to help
[02:50] <micahg> especially if you know they're migrating to 2.7, you can have a solid OS for about 4 years
[02:55] <blair> micahg, yes, maya will be on 2.7 in a year
[03:00] <ScottK> There will be a python2.6 PPA for precise.
[03:00] <ScottK> blair: ^^^
[03:01] <ScottK> Oh, no.
[03:01] <ScottK> Sorry.  Backwards.
[03:01] <ScottK> Launchpad needs a python2.7 PPA on lucid, not 2.6 on precise.
[03:02] <ScottK> In any case, you need to change python-defaults, python-central, python-support, and distribute and then build a python2.6 package and rebuild any modules/extensions you need.
[03:02] <ScottK> It's not a huge test to make such a PPA for someone familiar with the Debian/Ubuntu Python stack.
[03:04] <ScottK> In addition to this issue of python2.6 not being supported upstream, building python extensions for multiple versions adds to their size since they need double the .so files.
[03:05] <ScottK> For the extensions on the Ubuntu CD, a second python version adds about 8MB to the CD and space is constrained enough that 8 MB is a big deal.
[03:08] <blair> ScottK, thanks for the info, appreciate it.  excuse me getting worked up there, i was very much looking forward to this in precise, since I assumed it would be the same way as in oneiric
[03:08] <ScottK> No problem.
[03:09] <blair> is there a naming standard for a ppa like this?  precise-python2.6?
[03:09] <ScottK> All of the multiple support infrastructure is still there, so it's not that hard to do.
[03:09] <ScottK> PPAs aren't part of Ubuntu (they are built on Ubuntu) so there's no common standard.
[03:10] <ScottK> The only real standards for PPAs are version numbers to avoid conflict and confusion with packages from the official archive.
[03:10] <ScottK> Those standards are defacto, but some of us yell at people that don't follow them.
[03:11] <blair> i guess there's two ways to go, 1) tweak the builds to generate the packages with the exact same names and then have the PPA packages be picked up instead of Ubuntu's 2) have a system where a "2.6" is automatically put on the package name and they can coexist with Ubuntu's
[03:12] <ScottK> You generally use the same package name, just a different version to disambiguate them.
[03:14] <blair> so for "python-xattr" at 0.6.2-1ubuntu1, I would renumber it to something like 0.6.2-1ubuntu1-py26.1
[03:19] <blair> when ubuntu releases 0.6.2-1ubuntu2, then it would upgrade my package and remove the 2.6 pieces, which wouldn't be good
[03:20] <ScottK> Right, but post-release that's unlikely to be a problem.
[03:20] <ScottK> If it is, it's probably a big enough issue you want to rebuild your package.
[03:20] <ScottK> You can also use pinning to avoid the upgrade.
[03:22] <blair> this is good stuff, assuming we get buyin to move to 12.04, then i'll be doing this work
[07:14] <oojah> Laney: I contacted mt directly but haven't tried killian.
[07:15] <oojah> I'll try kilian.
[08:07] <Alison_Chaiken> Greetings MOTU.    I am packaging a set of programs that constitute a framework plus its plugins.
[08:07] <Alison_Chaiken> I've been pondering over how many packages to put them in.
[08:08] <Alison_Chaiken> The plugins support hardware accessories, and many users won't have many of them due to the expense.
[08:08] <Alison_Chaiken> So maybe each bit of HW should have a plugin which has its own package?
[08:09] <Alison_Chaiken> At least the base install should include all the components of the simulator environment for folks who have no HW at all, I figure.
[08:09] <Alison_Chaiken> I've pretty much got my brain around the mechanics of packaging, but now am thinking about these meta-issues.
[08:09] <Alison_Chaiken> Any thoughts about best practices are appreciated!
[08:11] <micahg> depending on size, you can split them, this is assuming they're all from the same source
[08:20] <Alison_Chaiken> So far, micahg, they're from the same source, but of course the hope is that accessory vendors will create their own plugins.
[08:21] <Alison_Chaiken> The point of making packages available in part is to make that process easier and more understandable for outside parties.
[08:21] <micahg> I meant split them in separate binaries, you can either do that for size or content or both, maintainer's choice
[08:21] <micahg> or neither
[08:21] <Alison_Chaiken> I have two ideas: one to package each plugin separately, and one to have a plugins-basic and plugins-extra.
[08:22] <Alison_Chaiken> Yeah, the binaries are already separate shared-object libraries, as plugins tend to be.
[08:22] <micahg> I meant binary packages as opposed to source
[08:23] <Alison_Chaiken> So the source all goes in one package logically unless it gets really big?
[08:23] <Alison_Chaiken> But the binaries get packaged separately?
[08:26] <micahg> umm, well, the source package produce one of more binary packages which can contain one or more (possibly binary) files
[08:26] <micahg> s/of more/or more/
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
=== dholbach_ is now known as dholbach
=== almaisan-away is now known as al-maisan
[09:06] <geser> Alison_Chaiken: look how libraries (usually) are packaged: the source (as it comes from upstream) is one tarball (= one source package) but it build several binary packages (deb files): one for the library itself, an other one for the headers (perhaps a third one with the documentaion)
=== al-maisan is now known as almaisan-away
=== _ruben_ is now known as _ruben
[11:37] <Rhonda> I wonder:  Is it the better approach to backport fonts-droid to older releases, or to adjust wesnoth-1.10 to work with ttf-droid instead?
=== chuck_ is now known as zul
[15:01] <Laney> happy birthday to highvoltage!
[15:03] <tumbleweed> he's naughty. had dinner with him last night, and he didn't warn us, only mentioned it at midnight on IRC
[15:03] <mitya57> Are here fans of unity-mail (or personally me) here? :) I need somebody to sponsor it for precise, see bug 927602.
[15:03] <ubottu> Launchpad bug 927602 in Ubuntu "[needs-packaging] unity-mail" [Wishlist,Triaged] https://launchpad.net/bugs/927602
[15:04] <highvoltage> thanks Laney :)
[15:04] <highvoltage> tumbleweed: yeah because my birthday only started at midnight!
[15:05] <Laney> could have procured some drinks :P
[15:05] <tumbleweed> and we *would* have kept you out :)
[15:05] <mitya57> BTW, Launchpad does no more allow to open new bugs via web ui, so it's impossible to easily open a needs-packaging bug - can it be fixed?
[15:05] <mitya57> P.S. Happy birthday!
[15:05] <Laney> mitya57: append ?no-redirect
[15:06] <Laney> +filebug?no-redirect or something ..
[15:06] <mitya57> Oh thanks, will use that next time
[15:06] <tumbleweed> it should explain that on the wiki page that it directs you to
[15:06] <Laney> yeah buried somewhere deep down
[15:06] <Laney> I think the process page for needs-packaging bugs contains a correct direct link
[15:07] <Laney> Rhonda: either works; doing the source change might be less of a pain depending on the extent of the changes required
[15:07] <highvoltage> Laney: I specifically wanted to avoid drinks, I was driving a loan car :)
[15:07] <Rhonda> Laney: Alright, and as I am keeping it in git I won't have any issues on upgrades anyway.
[15:08] <mitya57> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Requesting_a_new_package_for_Ubuntu contains a non-working link
[15:08] <Laney> fix it please :-)
[15:08] <tumbleweed> that has ?no-redirect
[15:08] <Laney> one of them does not
[15:10] <mitya57> sorry, I looked at wrong one
[15:10] <Laney> they should both work, please fix the other one
[15:11] <mitya57> Laney, done
[15:11] <Laney> nice
=== shadeslayer_ is now known as shadeslayer
=== koolhead17 is now known as koolhead17|zzZZ
[17:59] <Corey> Good morning, barry.
[17:59] <barry> hi Corey
[17:59] <Corey> barry: Yeah, apparently replacing python-support with python2 dh in Lucid isn't working yet.
[18:00] <Corey> There's a backport bug open for it, but it's been a year or better without progress.
[18:00] <barry> Corey: yeah.  you should ping doko on that :)
[18:05] <tumbleweed> I think it's fairly safe to assume at this point that it'll never happen
[18:07] <barry> yeah, probably so
[18:08] <tumbleweed> it's not always possible to make a package that'll build on all supported releases
[18:08] <tumbleweed> esp if you want new features
[18:12] <barry> tumbleweed: the problem is that it's not an insignificant amount of work.  i did look at it at one point, but got bogged down in details and bugs, so i'm not personally eager to try again.  however, if it were a significant problem for our users, then that's not good either
[18:13] <tumbleweed> OTOH, if we've survived this long...
[18:13] <barry> true, though not without grumbling ;)
[18:13] <tumbleweed> sure :)
[18:13] <barry> hey in 2 months we'll all forget what lucid was right? <wink>
[18:14] <tumbleweed> oh, did you see the dh_python2 bugfix I have in the sponsor queue for natty? I tried to get doko's attention on IRC, but iit looks like he misunderstood the bug
[18:14] <barry> tumbleweed: didn't see it
[18:14] <tumbleweed> bug 915167
[18:14] <ubottu> Launchpad bug 915167 in python-defaults (Ubuntu Natty) "pycompile will use /usr/local/bin/python2.X if available and python2.X is installed." [Medium,New] https://launchpad.net/bugs/915167
=== koolhead17|zzZZ is now known as koolhead17
[18:15] <barry> yuck
[18:16] <tumbleweed> yeah, it's suprising we didn't notice until now :)
[18:16] <tumbleweed> it was fixed almost immediately in debian
[18:16] <barry> indeed.  i almost always have some pythons in /usr/local/bin, but it's been a while since i ran natty
[18:26] <zooko> Folks: does anyone want to walk me through setting up autobuild recipe on launchpad?
[18:26] <zooko> There is presumably already a build config file/build script in existence, since the package gets built and included in Ubuntu releases.
[18:27] <zooko> And I just hooked up the "pull from github/git into launchpad/bzr" function.
[18:27] <zooko> So, what's left to do?
[18:27] <zooko> https://code.launchpad.net/~tahoe-lafs/tahoe-lafs/master/+new-recipe
[18:30] <jtaylor> zooko: if the debian package branch is ok, nest-part packaging lp:debian/tahoe-lafs debian should work
[18:30] <tumbleweed> zooko: prepare packaging that'll build on all the releases you want to daily build for, and write the recipe
[18:32] <zooko> jtaylor: this sounds like the right track, but I don't know how to check if the debian package branch is ok, and I don't know what "nest-part packaging" is. :-)
[18:32] <zooko> tumbleweed: that's the part I was asking for help with.
[18:33] <zooko> Oh shoot I have to go. I'll be back in about 3 hours
[18:33] <jtaylor> bzr dailydeb recipe to test it
[18:33] <zooko> .
[18:33] <tumbleweed> zooko: the recipe is trivial (look at the other recipes on lp, and you'll see how simple they are)
[18:33] <jtaylor> nest-part is merges the debian branch of the branch into the main one
[18:33] <jtaylor> *debian folder
[18:33] <jtaylor> https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[18:34] <jtaylor> though its more likely you will have to change the packaging, so you either branch the debian package or make a new branch
[18:34] <jtaylor> if you make a new branch only palce debian in it, then you can use a normal merge
[18:34] <zooko> jtaylor: I will try this later. Thanks! :-)
[19:26] <cancer> hey .. I wanna contribute to Ubuntu
[19:26] <cancer> where should I start from ?
=== tobin is now known as joshuaAFK
[20:43] <Corey> I'm attempting to upload a package to launchpad via dput, but it keeps kicking back an email: salt_0.9.6-2ubuntu1.dsc: Version older than that in the archive. 0.9.6-2ubuntu1 <= 0.9.6-lucid1
[20:43] <Corey> I've played with the version string, but can't get it to behave.
[20:44] <micahg> -lucid1 > -2ubuntu1
[20:45] <Corey> micahg: Ah.  So change it to lucid2?
[20:45] <micahg> see dpkg --compare-versions
[20:45] <micahg> Corey: what is the goal?
[20:45] <Corey> micahg: To update a package with a pile of changes to the packaging status, but is still 0.9.6 of upstream.
[20:45] <micahg> which release?
[20:46] <Corey> micahg: For Lucid, but also be portable to newer releases.
[20:46] <micahg> yeah, just bump it to lucid2 for a PPA
[20:46] <Corey> micahg: Okay.  Thank you. :p)
[20:49] <micahg> Corey: if you're interested in how the versioning works: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[20:51] <goddard> why doesn't bzr dh-make work?
[20:51] <goddard> it says unknown command?
[20:51] <Corey> micahg: I am-- thank you.
[20:52] <micahg> goddard: do you have bzr-builddeb installed?
[20:53] <goddard> not sure letme check
[20:53] <goddard> looks like no thanks
[20:55] <Corey> goddard: Yeah, I'm a fan of apt-file search for that.  (gotta apt-file update first, though)
[20:59] <goddard> Corey: i see
[20:59] <goddard> cool didnt know bout that
[21:08] <Corey> micahg: *siiiigh*  There are a few upstream changes to the orig.tar.gz in this version, but hte upstream version number didn't get bumped, so now I get File salt_0.9.6.orig.tar.gz already exists in Salt, but uploaded version has different contents.
=== joshuaAFK is now known as tobin
[21:09] <tumbleweed> Corey: then you need to turn those upstream changes into a quilt patch
[21:09] <micahg> Corey: right, so you either need to make the upstream changes patches against the original or change the upstream version ala 0.9.6+foo-0saltX
[21:10] <micahg> err...
[21:10] <micahg> upstream version = 0.9.6+foo
[21:10] <tumbleweed> or, you should include the upstream revision in the upstream version number, as micahg suggested
[21:10] <Corey> Thanks.
[21:10] <tumbleweed> (or you use native source format instead of quilt)
[21:12] <Corey> So the +foo gets applied to the orig tarball, and the version string in the changelog-- anywhere else?
[21:12] <micahg> well, source format 3.0 should make a patch for you depending on how it's configured
[21:13] <tumbleweed> fortunately, that's not a default any more
[21:13] <tumbleweed> Corey: no
[21:13] <Corey> Yeah, I'm not really interested in going the quilt route.
[21:14]  * micahg loved the "feature"
[21:14] <tumbleweed> the quilt route would make lots of sense if it was a package in the archive, and the tarball wasn't minute (then we wouldn't need a new copy of it every other week)
[21:15] <tumbleweed> but yes, generating a new tarball is easier :)
[21:17] <Corey> Accepted:
[21:17] <Corey> OK: salt_0.9.6+pre.orig.tar.gz
[21:17] <Corey> micahg, tumbleweed: You folks are gods among men.
[21:18] <micahg> Corey: well, that worked but the version seems counterintuitive (something to keep in mind for next time)
[21:18] <tumbleweed> yeah, was about to say the same thing :)
[21:18] <Corey> micahg: Yeah.  Technically it should probably have been 7.pre
[21:18] <tumbleweed> 6+pre > 6
[21:18] <micahg> usually + has a revno or something on top of the current release
[21:19] <Corey> But then I thought it'd hose me when .7 comes out in a week.
[21:19] <micahg> ~ is usually associated with pre-releases as it's lower
[21:19] <tumbleweed> if it's a pre for 7, you say 7~pre1 (or something like that)
[21:20] <micahg> or if you're not sure about the next version number, you just do 6+bzr1234 for example
[21:20] <micahg> that was a 6.1 release superseded
[21:20] <micahg> *supersedes
[21:20] <micahg> s/was/way/
[21:20] <micahg> can't really type today for some reason
[21:41] <tiox> Semitones thought I would suggest this.
[21:42] <tiox> I grabbed a package of ZSNES from Debian Wheezy (Thank goodness for pkgs.org) and modified the control file to depend on the lesser version of ia32-libs you guys have, and it works.
[21:43] <tiox> Not entirely sure if MORE stuff is needed, but I am fairly certain on a fresh install, the Wheezy package would complain about outdated ia32-libs, it looks for 20111001 instead of 20090808*
[21:44] <tiox> Oh, this is for 64-bit BTW. The zsnes:i386 package provided in the default repositories makes apt rage and want to remove 64-bit SDL.
[21:45] <tiox> As well as other things, some of the following, with depends: mplayer (medibuntu), blender, love, mupen64plus, cutemupen, electricsheep...
[21:48] <tiox> With that in mind, I'mma see how running the package from a 11.10 live CD does.
[21:48]  * micahg wonders why this is appropriate here
[21:49] <tiox> Because semitones (recently left) thought it would be a good idea to include a 64-bit compatible version of ZSNES in the Pangolin repositories.
[21:49] <tiox> Don't ask me why, lol
[21:49] <tiox> He directed me to you guys.
[21:49] <micahg> well, if there were buildable parts, sure
[21:50] <micahg> but the zsnes:i386 should work with multiarch, although the package FTBFS ATM
[21:50] <jtaylor> there is a merge bug for that somewhere
[21:50] <tiox> ?_? Huh?
[21:50] <tumbleweed> LGTM multiarch-wise
[21:50] <tiox> FTBFS? Whuzatmean?
[21:51] <tumbleweed> fails to build from source
[21:51] <tiox> Ah.
[21:51] <ajmitch> yes, there are too many acronyms
[21:51] <tiox> If I can fetch my log before I formatted my system to see if that would be a fix (I have nothing better to do), I'l show you what it tries to do.
[21:52] <tumbleweed> ajmitch: that one is particularly poorly documented (from my memory), but I tried to improve that
[21:52] <tumbleweed> tiox: you said an 11.10 CD, we are talking about 12.04
[21:52] <tumbleweed> IIRC sdl was only multi-arched recently
[21:52] <tiox> Well, I could test on 12.04 pre-release, but there's still two months + support time for 11.10
[21:53] <tiox> And it's what I have on hand right now.
[21:53] <micahg> ajmitch: WDYMTTATMA
[21:53] <micahg> wfm in 12.04
[21:54] <tiox> Sooo, BRB, AFK, TTYL, w/e, l8r.
[21:54] <ajmitch> HAND
[21:54] <tiox> Actually, forgot about that paste. Lemme lend that then I'll go.
[21:55] <tumbleweed> tiox: I agree that there's a problem here in oneiric, but I don' tthink it's easily dealt with
[21:56] <tumbleweed> (we aren't going to go around multi-arching things in SRUs)
[21:56] <tiox> I did'nt say it could be easily dealt with.
[21:56] <micahg> no, but if something was multi-archd improperly, it could be fixed in an SRU
[21:56] <micahg> *possibly be fixed
[21:57] <tiox> ANyway, here you go guys. http://paste.ubuntu.com/830846/
[21:57] <tumbleweed> it simply wasn't multiarched in oneiric
[21:57] <tiox> Quite an exhaustive list of things to remove just to install one program, no?
[21:57] <tumbleweed> tiox: everything that uses SDL
[21:58] <micahg> then why was it not in ia32-libs?
[21:59] <tumbleweed> not everything is in ia32-libs
[22:05] <tumbleweed> erm, what was I saying, it is in ia32-libs
[22:05] <tumbleweed> but we didn't build the crazy ia32libbed amd64 package, so he was trying to install the i386 package with multiarch
[22:06] <tumbleweed> jtaylor: done any numpy / sphinx experimentation?
[22:07] <jtaylor> numpy -4 works with sphins 1.12 if you mean that
[22:07] <tumbleweed> no I mean proposed transitions
[22:07] <jtaylor> I rebuilt the packages in precise, no failures
[22:09] <jtaylor> also no suspicous shlibdep warnings in regard to numpy
[22:09] <tumbleweed> oh, I see a sync bug
[22:09] <jtaylor> but one with libm which I should look at
[22:10] <jtaylor> barry took over sphinx
[22:10] <barry> jtaylor: i'm looking at it now.  is that cool?
[22:10] <jtaylor> there should be no issues with that either thanks to jwilk
[22:10] <jtaylor> yes of course
[22:11] <barry> i'm switching it back to dhpy2 in ubuntu >:-/
[22:11] <barry> jtaylor: are you going to work on the numpy update, given that doko is cool with it?
[22:11] <tumbleweed> is jwilk still holding out on dhp2?
[22:11] <jtaylor> too bad numpy has no py3 package yet :/
[22:11] <barry> tumbleweed: i guess so, the changes are truly minimal
[22:11] <jtaylor> barry: doko has no objects to it
[22:12] <barry> jtaylor: right, go for it!
[22:12] <jtaylor> I wonder if I should add py3 packages
[22:12] <barry> jtaylor: i'll happily sponsor uploads if necessary
[22:12] <barry> jtaylor: i'd say go for it if it's doable
[22:13] <barry> tumbleweed: maybe i should submit a bug on sphinx just to see what jwilk will say :)
[22:13] <jtaylor> I thinkthere is one already
[22:13] <tiox> By the graces of good fortune my package installed and worked.
[22:13] <barry> and it's funny 'cause he's already using dh_python3 (admittedly the only option)
[22:14] <jtaylor> no no bug yet
[22:14] <barry> jtaylor: right
[22:14] <barry> hey the worst that can happen is that he'll hate me for life
[22:15] <tumbleweed> barry: I think he's sponsored a package using dh_python2
[22:15] <barry> cool, maybe he's not opposed to it.  i'll test the change in ubuntu then and file a bug
[22:16] <tumbleweed> he was pretty opposed to it, but probably knows that python-support isn't going to be around forever
[22:16] <barry> it *is* officially deprecated after all
[22:17] <tumbleweed> yeah
[22:22] <zooko> jtaylor: regarding looking at an autobuild recipe, could you point me at a project that has a debian package and a working autobuild recipe on launchpad?
[22:23] <jtaylor> zooko: thats one of mine: https://code.launchpad.net/~jtaylor/+recipe/ipython-daily
[22:23] <jtaylor> its really very simple
[22:25] <zooko> Excellent, thanks.
[22:35] <jtaylor> barry: how soon are you syncing sphinx?
[22:35] <jtaylor> because I think its best to start numpy after that
[22:36] <barry> jtaylor: i'm working out a udd bug that the merge exposed.  looks like i won't be able to use udd merge to make it work, but as soon as i've verified that, i think i'll just requestsync it and then fix up the dhpy2 changes after that
[22:36] <barry> shouldn't be more than 15m or so
[22:36] <jtaylor> no rush, I probably won't get to numpy until friday anyway
[22:37] <barry> jtaylor: cool.  i'm off-line on friday, but i can sponsor stuff on monday if you can't find another sponsor
[22:37] <jtaylor> py3 numpy looks like a challenge judging by the length of the rules file, I think I'll first get the transition done first and have a go at py3 if there is still time after that
[22:38] <barry> +1
[22:41] <Corey> Hmm.  Why would a dsc that builds into several packages here (common, master, etc) only spit out common in a PPA?
[22:41] <jtaylor> Corey: buildlog?
[22:43] <barry> jtaylor: syncpackaged sphinx 1.1.2+dfsg-4.  once that gets processed i'll upload a -4ubuntu1 to switch to dhpy2, but that shouldn't affect the numpy builds
[22:43] <jtaylor> barry: you'll also take care of the few packages that are broken?
[22:44] <barry> jtaylor: the ones that are listed in bug 911124 yes
[22:44] <ubottu> Launchpad bug 911124 in sphinx (Ubuntu) "Please sync python-sphinx 1.1.2 from Debian experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/911124
[22:45] <Corey> jtaylor: https://launchpadlibrarian.net/92347092/buildlog_ubuntu-lucid-amd64.salt_0.9.6%2Bpre-lucid2_BUILDING.txt.gz
[22:46] <tumbleweed> Corey: on amd64, only the architecture-dependant packages will build (assumin gyou also have arch all packages)
[22:46] <Corey> tumbleweed: OH!  So it'll populate out when the i386 stuff completes in 2-3 hours?
[22:47] <tumbleweed> I don't know why salt-common is architecture-dependant, it looks pretty independanty to me
[22:47] <tumbleweed> independant
[22:47] <Corey> tumbleweed: You're right.
[22:47] <Corey> tumbleweed: There used to be a compiled msgpack element, but that was broken out into another package.
[22:47] <tumbleweed> anyway, arch:all packages are built on i386 on Ubuntu
[22:49] <Corey> tumbleweed: And while I'm fixing things, the version string should go from 0.9.6+pre-lucid2 to 0.9.7~pre1-lucid2?
[22:49] <Corey> Or am I not quite right?
[22:50] <tumbleweed> if that describes it better, sure
[22:50] <jtaylor> the -lucid is a bit weird
[22:50] <jtaylor> - has special meaning in packages, I'd remove it
[22:50] <jtaylor> replace it with -0lucid1 or ~lucid1 or +lucid1
[22:50] <Corey> Ah.
[22:50] <tumbleweed> you want to have a -, this packgae isn't native
[22:51] <tumbleweed> -0lucid1 or -0ppa1 is probably best
[22:51] <Corey> 0.9.7~pre1-0ppa1 <-- this?
[22:51] <tumbleweed> LGTM
[22:51] <Corey> tumbleweed: And then when I fix the next bug, it becomes pre2?
[22:51] <tumbleweed> Corey: depends what you change
[22:52] <tumbleweed> if you change something upstream, pre2, ifyou change something in the packaging (or fix a bug with a quilt patch) -0ppa2
[23:03] <Corey> tumbleweed: https://github.com/KB1JWQ/salt/blob/master/debian/control <-- If I don't want fun things like 'gcc' being auto-depped in at install, I should leave them in build-depends and remove them from the common package?
=== arand_ is now known as arand
[23:09] <tumbleweed> Corey: why does salt-common need python-dev?
[23:10] <Corey> tumbleweed: It doesn't in my latest change.  I'm stripping things out now.
[23:10] <Corey> tumbleweed: I'm also not convinced that the build-dep needs it either.
[23:10] <barry> jtaylor: given that your work on numpy will cause the proper rebuild, do we actually need to rebuild virtualenv for the new sphinx?
[23:10] <tumbleweed> you are building python extensions with cython, so you'll need python-dev
[23:12] <tumbleweed> Corey: I don't understand your question about gcc
[23:12] <jtaylor> :q
[23:12] <jtaylor> does virtualenv depend on numpy?
[23:13] <jtaylor> also not every depend must be rebuilt, only the ones using the C-api
[23:13] <barry> hmm, i guess not.  i was just going by the comment in the sphinx bug, but not according to python-virtualenv/d/control
[23:13] <barry> so ignore virtualenv
[23:13] <jtaylor> the problematicone is virtualenvwrapper not virtualenv
[23:14] <barry> ah
[23:14] <jtaylor> and we need a new upstream of that so the rebuilt will happen in any case
[23:14] <barry> i think rebuild is probably only necessary if the docs are broken (which would probably ftbfs the package)
[23:14] <jtaylor> virtualenvwrapper in precise ftbs with sphinx 1.12
[23:14] <jtaylor> you need .11-2 from unstable
[23:15] <barry> okay.  i think we can take care of pymvpa2 by just sync'ing 2.0.0-6 from sid.  double checking diffs
[23:15] <jtaylor> pymvpa already fixed?
[23:15] <barry> jtaylor: can you add that to the sphinx bug comments.  i'll make sure it's working before i close that bug
[23:15] <barry> jtaylor: checking that now
[23:15] <jtaylor> the bug is still open
[23:16] <barry> the sphinx bug yes, but i don't think it mentions venvwrapper
[23:16] <barry> oh, it's just a typo. nm, i'll do that
[23:17] <jtaylor> oh pymvpa2 not one
[23:17] <jtaylor> it mentions the wrapper, though I named in venv :/
[23:17] <jtaylor> the link is correct though
[23:17] <barry> yep
[23:32] <blair> ScottK, i started a ppa to manage the python 2.6 for precise.  in your note from yesterday, you said "you need to change python-defaults..." but i cannot find that package
[23:33] <stgraber> blair: apt-cache showsrc python-defaults
[23:33] <stgraber> it's the source package building: python, python-minimal, python-examples, python-dev, idle, python-doc, python-dbg, python-all, python-all-dev, python-all-dbg
[23:33] <jtaylor> barry: just in case you didn't notice, sphinx now dep waits for -support as that was demoted
[23:34] <blair> thanks, i tried apt-cache search and it came up empty
[23:34] <stgraber> blair: right, because there's not binary package called python-defaults, it's only the name of the source package
[23:34] <blair> i'll check both in the future :)
[23:35] <stgraber>   o python-support: python-support
[23:35] <stgraber>     [Reverse-Build-Depends: sphinx (MAIN)]
[23:35] <stgraber>  
[23:35] <stgraber>   o python-whoosh: python-whoosh python-whoosh-doc
[23:35] <stgraber>     [Reverse-Depends: Rescued from python-whoosh]
[23:35] <stgraber>     [Reverse-Build-Depends: sphinx (MAIN)]
[23:35] <stgraber> jtaylor, barry: ^
[23:35] <barry> jtaylor: crap.  guess i gotta make that fix now then.
[23:35] <stgraber> (just showed up on the release team mailing-list)
[23:36] <jtaylor> < offline, probably back friday evening, bye