[08:20] <dholbach> good morning
[10:25] <tumbleweed> jtaylor: got to the bottom of that networkx thing yet? I saw another mail on the debian epigrass bug
[13:19] <ockham> http://packages.debian.org/de/sid/tesseract-ocr has been recently updated to version 3.* in debian (finally!). if i want to have this in precise, is it better to wait the 10 days until it's in debian testing and file a sync request then (which will be around the 13th, which is shortly before FeatureFreeze on the 16th) or file it right now?
[13:29] <geser> ockham: if you are confident that the packages will work, you can sync them now
[13:34] <ockham> geser: hm, i haven't really checked yet; so maybe it's better to wait until it's in testing at least.
[13:34] <ockham>  if i filed a sync request between 13th and 16th, it would still get into precise, right?
[13:35] <obounaim> when will the next udw happen?
[13:57] <geser> May 7th - May 11th, Oakland, CA
[13:57] <geser> http://uds.ubuntu.com/
[14:00] <ockham> thats uds, not udw
[14:01] <ockham> obounaim: did you mean developer week or summit?
[14:01] <ockham> info for week is at https://wiki.ubuntu.com/UbuntuDeveloperWeek
[14:01] <ockham> but nothing yet on the next one... :-(
[14:02] <obounaim> ockham: week
[14:03] <geser> ah, week, misread it
[14:03] <geser> isn't udw usually once per release cycle?
[14:03] <geser> dholbach should know it :)
[14:05] <dholbach> yes, it's one per release
[14:06] <dholbach> and the date for the next one is not scheduled yet
[14:09] <obounaim> ok thanks
[14:48] <obounaim> i have noticed that when i'm using ubuntu my battery goes done faster than when i'm using is this a bug
[14:51] <obounaim> when i'm using windows sorry
[14:58] <tumbleweed> obounaim: I'm afraid this isn't a user support channel. I'd consider that a bug, but that won't help you much. Is it newish hardware? Have you tried the latest mainline kernel, maybe it'll be better...
[18:24] <jtaylor> tumbleweed: @networkx yes I uploaded fixes to -proposed
[18:24] <jtaylor> that answer is weird, recommending installing debian packages over just installing setuptools o_O
[18:28] <tumbleweed> oh, right, it was an SRU
[18:29] <tumbleweed> err, I don't see it in unapproved
[18:31] <jtaylor> hm they where rejected :/
[18:31] <tumbleweed> :)
[18:31] <jtaylor> thought I don't know why
[18:31] <tumbleweed> the archive admin should tell you
[18:32] <tumbleweed> err SRU team member
[18:36] <jtaylor> RAOF: ^
[18:46] <jtaylor> tumbleweed: as your at it python-gd is can be synced to precise and SRU'ing to oneiric ;)
[18:47] <tumbleweed> hah
[18:49] <ajmitch> morning
[18:49] <jtaylor> what are sru reject reasons?
[18:50] <ajmitch> bad changelog, bug fix is too invasive, no tests for reproducing the bug?
[18:50] <jtaylor> all not the case :/
[18:51] <jtaylor> oh I missed closing the bug in the changelog
[18:51] <jtaylor> reject reason?
[18:51] <ajmitch> might be, I'd expect an email explaining why though
[18:51] <jtaylor> no, just rejected :(
[18:52] <jtaylor> but the bug reference is important so its probably the reason
[18:52] <jtaylor> too bad I had my branches in /tmp and did not push them :(
[18:53] <tumbleweed> well, you also can't push to branches that don't exist
[18:53] <tumbleweed> which is the case here
[18:53] <jtaylor> to my personal space I meant
[19:33] <jtaylor> hm I found another issue of the natty package, a missing numpy dependency, do I have to open a new bug for that?
[19:33] <jtaylor> when fixing in the same sru
[19:34] <tumbleweed> prentend that they are the same issue ("missing dependencies") :)
[19:35] <jtaylor> missing != to strict :/
[19:36] <jtaylor> I just rename it to dependency issues :)
[19:36] <davromaniak> good evening
[19:37] <davromaniak> we are having issues with the nginx builds
[19:37] <davromaniak> for the 1.1.12, the build failed for every arch except amd64
[19:38] <davromaniak> I tried to apply a fix, and for the 1.1.14, the build failed only for amd64
[19:38] <davromaniak> in the 1.1.12 I added the possibility of using a threaded build
[19:39] <jtaylor> ok now I just still need to find a release team member to confirm the reject reason
[19:40] <davromaniak> And I would like somebody experienced to help me (and the nginx packaging team on Debian) to review the debian/rules file and the build log, to see what's wrong and why the build failed only on amd64
[19:41] <tumbleweed> jtaylor: release team != SRU
[19:41] <tumbleweed> but yes, that seems the most likely reason
[19:42] <tumbleweed> davromaniak: nice build failure
[19:43] <davromaniak> :)
[19:43] <tumbleweed> that looks pkgbinarymangler related
[19:44] <davromaniak> the strange thing is that there's no build issue on Debian, so before the import to ubuntu, we were unable to prepare ourselves for a build failure
[19:44] <tumbleweed> well, you can set up an ubuntu chroot on your debian system :)
[19:45] <davromaniak> yes, and I can't reproduce it
[19:45] <tumbleweed> did you install pkgbinarymangler in the chroot?
[19:45] <davromaniak> tumbleweed: is it installed by default in a pbuilder ?
[19:46] <tumbleweed> davromaniak: probably not
[19:46] <davromaniak> ok
[19:46] <davromaniak> I'm updating my precise pbuilders, and I will install pkgbinarymangler in it
[19:47] <tumbleweed> hrm, a while since I used pbuilder, but I don't see it in my pbuilderrc anywhere
[19:47] <tumbleweed> and I certainly used to have it installed
[19:47] <tumbleweed> ah, I added a hook script to install it
[19:48] <davromaniak> ok
[19:48] <davromaniak> is pkgbinarymangler used on the system building packages for the PPAs ?
[19:49] <tumbleweed> IIRC yes
[19:49] <davromaniak> ok
[19:49] <davromaniak> No build failed for the nginx PPA
[19:49] <tumbleweed> although it might be configured differently in PPA builds
[19:49] <davromaniak> ok
[19:49] <tumbleweed> they don't do ddebs
[19:49] <tumbleweed> which is the issue here
[19:50] <davromaniak> ok
[19:51] <tumbleweed> meh, my build didn't fail
[19:51] <davromaniak> ah
[19:52]  * tumbleweed tweaks pkgbinarymangler knobs
[19:55] <jtaylor> actually this numpy issue is interesting
[19:55] <jtaylor> newer versions do not need numpy anymore
[19:55] <jtaylor> whats better, backport the few try except blocks or move numpy from recommend to depend?
[19:55] <davromaniak> tumbleweed: I'm trying the build with 8 threads
[19:56] <broder> pkgbinarymangler definitely knows whether it's doing a Real Archive build or a PPA build
[19:56] <broder> (and it disables a bunch of stuff for PPA builds)
[19:56] <tumbleweed> jtaylor: depending on numpy is probably simpler
[19:56] <tumbleweed> davromaniak: btw, +1 for enabling parallel builds :)
[19:56] <davromaniak> maybe there's an issue with parallel builds and pkgbinarymangler
[19:57] <tumbleweed> the parallelism should only apply to the sub-makes, IIRC
[19:58] <davromaniak> tumbleweed: could you check the debian/rules file ?, maybe I made something wrong
[19:58] <davromaniak> here : http://anonscm.debian.org/viewvc/collab-maint/deb-maint/nginx/trunk/debian/rules?view=markup
[20:00] <davromaniak> so just finished the build, and no issue :(
[20:00] <tumbleweed> yeah, I'd like to duplicate it before guessing what the problem is
[20:03] <davromaniak> so now, 16 threads on another server
[20:03] <tumbleweed> it could be the paralellism... My only experience is with dh's --parallel, not changing MAKEFLAGS
[20:04] <davromaniak> It's the first time I enable paralellism in a package
[20:04] <davromaniak> and I took inspiration on other packages
[20:04] <davromaniak> also, the structure of the nginx packaging is so particular we can't use the compressed dh format
[20:17] <jtaylor> tumbleweed: won't adding a depend require a dist-upgrade?
[20:17] <jtaylor> is that ok in a sru?
[20:18] <tumbleweed> jtaylor: err, upgrade should install new packages, dist-upgrade allows removals
[20:18] <tumbleweed> not an SRU team member, so :)
[20:19] <jtaylor> it doesn'T in precise
[20:19] <jtaylor> when there are new packages you need to dist-upgrade
[20:20] <tumbleweed> but new dependancies certainly aren't unheared of in SRUs
[20:20] <tumbleweed> we even have new binary packages in SRUs
[20:20] <jtaylor> k
[20:26] <davromaniak> so, I just compared build logs for threaded and not threaded builds, and I think I messed up the parallelism in the debian/rules
[20:27] <davromaniak> the structure of nginx packaging is not common, so I will have to perform more research and tests before definitively activate parallel build
[20:27] <tumbleweed> I suggest just using a variable containing -jX that you add to $(MAKE) command lines
[20:27] <tumbleweed> (that's what dh does)
[20:28] <davromaniak> ok, but the MAKEFLAGS variable is not used for this ?
[20:28] <tumbleweed> then you get parallism for the upstream Makefile (which is parallel-safe) and don't for debian/rules, which appears not to be
[20:28] <davromaniak> hmmm, ok
[20:29] <tumbleweed> yes, that's the definition of MAKEFLAGS, but it seems to affect the parent make too...
[20:39] <blair> i saw some work on the pyside 1.1.0 upgrade (thanks micahg), but they haven't appeared on my precise system yet, what's the status of them?
[20:39] <micahg> blair: I only did one package :), probably stuck in NEW
[20:39] <davromaniak> thanks tumbleweed. I will try to make the new package imported into Ubuntu before the feature freeze
[20:39] <blair> that means what (for the uninformed)?
[20:40] <micahg> needs archive admin review for a new binary
[20:40] <micahg> should be pushed through later today or early next week
[20:42] <tumbleweed> there were a few rounds o fstuck in NEW
[20:43] <tumbleweed> davromaniak: there's no crazy hurry, we can fix that after FF
[20:43] <davromaniak> you are right, as it's an issue
[20:44] <tumbleweed> thanks for taking an interest in it in Ubuntu :)
[20:44] <davromaniak> :)
[20:59] <ScottK> blair: I sync'ed the other packages.  As micahg said, we need to wait for New processing to get done, but it's in before feature freeze now, so there's not a schedule related rush.
[21:01] <blair> ScottK, thanks!
[21:14] <blair> found this really cool tool to run jobs in parallel from a shell, kinda like xargs, but neither debian nor ubuntu has it (http://www.gnu.org/software/parallel/man.html#example__compute_intensive_jobs_and_substitution)
[21:15] <jtaylor> yey thats a sad story
[21:15] <jtaylor> it conflicts with moreutils
[21:15] <jtaylor> and neither want to rename their tool
[21:16] <jtaylor> there is a package on mentory that is usuable
[21:16] <jtaylor> mentors
[21:18] <blair> which version of parallel is better and/or has more features?
[21:18] <jtaylor> gnu
[21:18] <jtaylor> moreutils parallel is very poor compared
[21:18] <jtaylor> its pretty much xargs -P
[21:19] <jtaylor> with ordering
[21:19] <blair> couldn't it be treated like the two dd_rescue versions?  or have gnu parallel be installed as gparalle?
[21:20] <jtaylor> gnu parallel has gained a --tollef mode to make it parallel installable
[21:20] <jtaylor> but I think the packager gave up
[21:21] <jtaylor> let me dig out the itp
[21:23] <jtaylor> debian bug 518696
[22:20] <iulian> Laney: http://packages.qa.debian.org/g/ghc/news/20120203T183507Z.html
[22:20] <iulian> OK, it looks like we have to keep doko's aclocal.m4 changes. I haven't seen any news with regards to that patch.
[22:22] <iulian> It also seems that upstream didn't comment on it either. Uhm.
[22:23] <iulian> Unless there were some off list discussions.
[22:41] <blair> what's the difference between this channel and the ubuntu+1 channel, seems like the general topic is the same?
[22:43] <jtaylor> ubuntu+1 is more a user channel for +1 only, this is more developer orientated for all releases
[22:45] <blair> ok, thanks
[22:52] <micahg> quadrispro: I'm going to try to update gmusicbrowser in Debian git over the weekend
[22:53] <astraljava> micahg: Are there possibilities in backporting it to oneiric? I'd be interested.
[22:59] <micahg> astraljava: sure, let's discuss later
[22:59] <astraljava> micahg: Great, thanks!
[23:18] <jtaylor> what is actually the process on sponsoring merge proposals`?
[23:19] <jtaylor> just build and dput as usual + marking the proposal as merged or is there some real merging involved somewhere?
[23:21] <debfx> jtaylor: you merge the branch, tag and push it and then dput the package
[23:24] <jtaylor> push to e.g. lp:ubuntu/release-proposed/<package-name>?
[23:30] <debfx> I guess but I haven't actually done an SRU with udd