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