dholbach | good morning | 08:20 |
---|---|---|
=== 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 | ||
tumbleweed | jtaylor: got to the bottom of that networkx thing yet? I saw another mail on the debian epigrass bug | 10:25 |
=== Quintasan_ is now known as Quintasan | ||
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:19 |
geser | ockham: if you are confident that the packages will work, you can sync them now | 13:29 |
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:34 |
obounaim | when will the next udw happen? | 13:35 |
geser | May 7th - May 11th, Oakland, CA | 13:57 |
geser | http://uds.ubuntu.com/ | 13:57 |
ockham | thats uds, not udw | 14:00 |
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:01 |
obounaim | ockham: week | 14:02 |
geser | ah, week, misread it | 14:03 |
geser | isn't udw usually once per release cycle? | 14:03 |
geser | dholbach should know it :) | 14:03 |
dholbach | yes, it's one per release | 14:05 |
dholbach | and the date for the next one is not scheduled yet | 14:06 |
obounaim | ok thanks | 14:09 |
=== dholbach_ is now known as dholbach | ||
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:48 |
=== al-maisan is now known as almaisan-away | ||
obounaim | when i'm using windows sorry | 14:51 |
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... | 14:58 |
=== glebihan_ is now known as glebihan | ||
=== yofel_ is now known as yofel | ||
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:24 |
tumbleweed | oh, right, it was an SRU | 18:28 |
tumbleweed | err, I don't see it in unapproved | 18:29 |
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:31 |
tumbleweed | err SRU team member | 18:32 |
=== arunsonnet is now known as arun_sram | ||
jtaylor | RAOF: ^ | 18:36 |
jtaylor | tumbleweed: as your at it python-gd is can be synced to precise and SRU'ing to oneiric ;) | 18:46 |
tumbleweed | hah | 18:47 |
ajmitch | morning | 18:49 |
jtaylor | what are sru reject reasons? | 18:49 |
ajmitch | bad changelog, bug fix is too invasive, no tests for reproducing the bug? | 18:50 |
jtaylor | all not the case :/ | 18:50 |
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:51 |
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:52 |
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 | 18:53 |
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:33 |
tumbleweed | prentend that they are the same issue ("missing dependencies") :) | 19:34 |
jtaylor | missing != to strict :/ | 19:35 |
jtaylor | I just rename it to dependency issues :) | 19:36 |
=== bregma is now known as bregma|afk | ||
davromaniak | good evening | 19:36 |
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:37 |
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:38 |
jtaylor | ok now I just still need to find a release team member to confirm the reject reason | 19:39 |
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:40 |
tumbleweed | jtaylor: release team != SRU | 19:41 |
tumbleweed | but yes, that seems the most likely reason | 19:41 |
tumbleweed | davromaniak: nice build failure | 19:42 |
davromaniak | :) | 19:43 |
tumbleweed | that looks pkgbinarymangler related | 19:43 |
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:44 |
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:45 |
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:46 |
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:47 |
davromaniak | ok | 19:48 |
davromaniak | is pkgbinarymangler used on the system building packages for the PPAs ? | 19:48 |
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:49 |
davromaniak | ok | 19:50 |
tumbleweed | meh, my build didn't fail | 19:51 |
davromaniak | ah | 19:51 |
* tumbleweed tweaks pkgbinarymangler knobs | 19:52 | |
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:55 |
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:56 |
tumbleweed | the parallelism should only apply to the sub-makes, IIRC | 19:57 |
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 | 19:58 |
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:00 |
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:03 |
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:04 |
jtaylor | tumbleweed: won't adding a depend require a dist-upgrade? | 20:17 |
jtaylor | is that ok in a sru? | 20:17 |
tumbleweed | jtaylor: err, upgrade should install new packages, dist-upgrade allows removals | 20:18 |
tumbleweed | not an SRU team member, so :) | 20:18 |
jtaylor | it doesn'T in precise | 20:19 |
jtaylor | when there are new packages you need to dist-upgrade | 20:19 |
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:20 |
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:26 |
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:27 |
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:28 |
tumbleweed | yes, that's the definition of MAKEFLAGS, but it seems to affect the parent make too... | 20:29 |
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:39 |
micahg | needs archive admin review for a new binary | 20:40 |
micahg | should be pushed through later today or early next week | 20:40 |
tumbleweed | there were a few rounds o fstuck in NEW | 20:42 |
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:43 |
tumbleweed | thanks for taking an interest in it in Ubuntu :) | 20:44 |
davromaniak | :) | 20:44 |
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. | 20:59 |
blair | ScottK, thanks! | 21:01 |
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:14 |
jtaylor | yey thats a sad story | 21:15 |
jtaylor | it conflicts with moreutils | 21:15 |
jtaylor | and neither want to rename their tool | 21:15 |
jtaylor | there is a package on mentory that is usuable | 21:16 |
jtaylor | mentors | 21:16 |
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:18 |
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:19 |
jtaylor | gnu parallel has gained a --tollef mode to make it parallel installable | 21:20 |
jtaylor | but I think the packager gave up | 21:20 |
jtaylor | let me dig out the itp | 21:21 |
jtaylor | debian bug 518696 | 21:23 |
ubottu | Debian bug 518696 in wnpp "ITP: parallel -- build and execute command lines from standard input in parallel" [Wishlist,Open] http://bugs.debian.org/518696 | 21:23 |
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:20 |
iulian | It also seems that upstream didn't comment on it either. Uhm. | 22:22 |
iulian | Unless there were some off list discussions. | 22:23 |
blair | what's the difference between this channel and the ubuntu+1 channel, seems like the general topic is the same? | 22:41 |
jtaylor | ubuntu+1 is more a user channel for +1 only, this is more developer orientated for all releases | 22:43 |
blair | ok, thanks | 22:45 |
micahg | quadrispro: I'm going to try to update gmusicbrowser in Debian git over the weekend | 22:52 |
astraljava | micahg: Are there possibilities in backporting it to oneiric? I'd be interested. | 22:53 |
=== almaisan-away is now known as al-maisan | ||
=== al-maisan is now known as almaisan-away | ||
micahg | astraljava: sure, let's discuss later | 22:59 |
astraljava | micahg: Great, thanks! | 22:59 |
=== yofel_ is now known as yofel | ||
jtaylor | what is actually the process on sponsoring merge proposals`? | 23:18 |
jtaylor | just build and dput as usual + marking the proposal as merged or is there some real merging involved somewhere? | 23:19 |
debfx | jtaylor: you merge the branch, tag and push it and then dput the package | 23:21 |
jtaylor | push to e.g. lp:ubuntu/release-proposed/<package-name>? | 23:24 |
debfx | I guess but I haven't actually done an SRU with udd | 23:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!