[00:26] Would someone take a look at python(3)-urwid with me.. I would like to request a merge, but I'm unable to figure out the delta and if it needs to be merged or if the delta can be removed and synced. === cjohnston_ is now known as cjohnston === murthy is now known as murthy_ === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === Logan_ is now known as Guest15281 === Logan__ is now known as Logan_ [08:06] good morning [08:24] good morning === almaisan-away is now known as al-maisan === zequence_ is now known as zequence [11:52] cjohnston: for what? [12:16] bdrung: bug #1139097 [12:16] bug 1139097 in dh-make (Ubuntu) "Sync dh-make 0.62 (main) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/1139097 [12:35] cjohnston: you're welcome :) [13:00] hey guys, our package, on the course of making it to the archive, seems to be stuck in the NEW queue. is there anything that can be done? [13:01] jokerdino: Debian or Ubuntu's NEW queue? [13:01] either way, not much to be done, just sit back and wait [13:01] tumbleweed: the Ubuntu queue. it's been in the queue for a couple days now. [13:02] jokerdino: reviewing new packages takes time [13:02] ah, I thought MOTU's review is enough? [13:02] no. ftp-masters in Debian, and archive-admins in Ubuntu do a final review [13:03] mostly checking that the package is distributable [13:03] right then. i am just worried about the feature freeze deadline. [13:03] it's in NEW before the freeze, so that's ok [13:03] also, sounds like the freeze may go away :P [13:04] haha, i dont know [13:04] tumbleweed: also, i think you would be a good guy to bounce some stuff off. [13:04] right now, I'd bet on it going away [13:04] the package I am talking about is a unity tweak tool. the rolling release might break our package any time. [13:05] that's to be expected in any development release [13:05] rolling just means the development release rolls for longer :P [13:05] for another year or so. [13:05] so, if it breaks, fix it ASAP [13:05] so, in that case of breakage, will the review work fasteR? [13:06] probably not, but after several uploads, if your sponsors agree, you can apply for PPU rights [13:07] actually, that's sorta what I have in mind. [13:07] the rolling release idea got me confused [13:08] and i think it is more than likely they will get on rolling. [13:08] the discussion invitation seems namesake. [13:08] morning all! does anyone here have any idea how to remove 'fuzz' from a quilt patch? im creating two patches, the first one applies fine, the second doesn't.. patch works outside of pdebuild, but not inside.. docs seem to suggest its due to fuzzing not being accepted in dpkg-source/dpkg-buildpackage.. but i cant seem to find anything that explains how to fix this problem.. any thoughts? [13:09] (done the usual homework, my google-fu fails me this time) [13:10] quilt push; quilt refresh (repeat for all patches) [13:10] thanks - ah, i didnt do the push on each step, only the refresh. let me try that, sec [13:11] some may not apply with a push, then things get extra fun [13:11] heh, im scared. [13:23] tumbleweed: sadly that still failed :X if you have a moment, would you mind reviewing on pastebin? http://pastebin.com/ALJf6id1 - its got the command sequence i used, the output of pdebuild, and the patch contents.. ive tried so many combinations to make this work :/ [13:23] its not even a complex patch, its like 1 line lol [13:23] 1 line patch on a 3 line file :X [13:31] foxx2: what's the output of debuild -S -uc -us [13:31] also, why are you using --include-binaries? [13:32] same output.. include-binaries because otherwise it refuses to add the precompiled binary files :/ [13:33] why are you precompiling binary files? [13:33] (just in case - http://pastebin.com/gtxDi8d4 ) [13:33] oh, its for an existing non-free software called Atlassian Bamboo [13:33] sure [13:33] they dont give the source away :/ [13:34] --include-binaries is about modifications you've made to the source package, not the source you got from upstream [13:34] ohhh [13:34] the manpage says: "Add all modified binaries in the debian tarball." [13:34] okay that makes sense, i shall remove that thenm [13:35] yes [13:35] if you find yourself using it, you are probably doing something wrong [13:35] sadly same hunk error still lol [13:35] haha okay :) [13:35] right, so it looks like dpkg-source thinks that you haven't got any patches applied [13:35] try quilt pop -a; then debuild -S ? [13:35] was just aboutt o say, should i try pop - sec [13:36] (I don't know why it thinks that, though because it should handle that situation) [13:36] same - http://pastebin.com/qrAbENq2 [13:36] but if you quilt push, they apply? [13:37] quilt push; quilt apply? [13:37] quilt push -a [13:38] (quilt doesn't have an apply command) [13:38] odd that seems to have only applied 1 patch [13:38] http://pastebin.com/5p1pYj0C [13:38] oh, I think you misread they as then [13:38] ahh sorry lol [13:39] I thought you had two patches? I only see one there [13:39] the fix-debian-target.patch doesnt seem to come up [13:39] yeah lemme try pop again, sec [13:39] okay there we go; [13:39] http://pastebin.com/BXBGNB7k [13:39] seems to apply without problem [13:40] weird [13:40] is this a common problem? [13:40] no [13:40] lol well thats just great.. anything i could look at that might assist in debugging? any verbose output or anything? [13:41] not sure if this is relevant but [13:41] $ cat src/webapp/WEB-INF/classes/bamboo-init.properties.rej [13:41] cat: src/webapp/WEB-INF/classes/bamboo-init.properties.rej: No such file or directory [13:41] no, not relevant [13:41] you sure you haven't made any modifications to src/webapp/WEB-INF/classes/bamboo-init.properties that aren't represented in the patches? [13:42] my guess is that quilt is basing the patches against something that wasn't the original source [13:42] (it backs up the original source to the .pc directory, when you quilt add a file, so that it can generate diffs) [13:42] almost 100% positive.. i even did all this from hand 3 times in a row with no automation just to be sure [13:42] so, try extract the upstream tarball in a new directory, copy your debian directory in, and see if the quilt patches apply [13:42] okay 2 secs [13:43] (ty for the help btw, much appreciated) [13:43] slow day today (or I'm being lazy, or something) :) [13:44] hmm, same thing.. (ls output + patch error) - http://pastebin.com/mBfdXf2G [13:44] i did a fresh extract from the orig tar into a new dir [13:45] cp -Ra the debian dir, etc [13:45] err [13:45] your source package cotains a tarball? [13:45] oh wait [13:45] now we have something [13:45] http://pastebin.com/MDfmqDRD [13:45] now when i do push -a manually, it fails [13:45] (i did pop before hand too) [13:46] it looks like you are doing things in the wrong directories [13:46] atlassian-bamboo-4.4.4.tar.gz should be called atlassian-bamboo_4.4.4.orig.tar.gz [13:46] debian should be inside atlassian-bamboo-4.4.4 [13:46] ahhh, sorry yes i messed that up, let me try again, sec [13:48] heh i think i know what i did wrong, 2 mins just testing now === al-maisan is now known as almaisan-away [14:02] tumbleweed: it works! :) so here was the problem.. because the dir layout of the atlassian bamboo tar is a bit messy, i was making some changes to the folder structure AFTER creating the .orig.tar.gz file (so orig contained the old layout, but the extracted dir contained the new layout), which in my case, was renaming a root dir and moving all the contents inside to a dir called 'src/'.. [14:02] when running the patches on this dir it worked fine, but of course when pbuilder kicked in, it was using .pc, which threw up massive differences which it couldnt figure out (and rightly so)... the fix was to extract the tar, make the changes, create a new tar with this dir struct and rename to the appropriate .orig.tar.gz file, apply the usual patch structure, then it worked fine [14:03] your original guess of "are you sure you havent changed anything" was correct :) [14:03] I try and avoid repacking orig tarballs, unless I need to remove undistributable bits [14:04] what if the original tarball changes its foldername on every release? i.e. inside the tar is SOFTWARE-VERSION.VERSION.VERSION [14:04] if you do need to, I suggest automating it for next time (e.g. with a get-packaged-orig-source rule in debian/rules) [14:04] it doesn't matter what the top level directory name in the tarball is [14:04] oh holy shit, i didnt know about get-packaged-orig-source [14:04] (as long as there is only one top level directory) [14:05] foxx2: there isn't, but it's the (semi-)standard name for a rule that does this [14:05] ah [14:05] go fundementally i need to change my approach on automating this.. got it [14:05] either automate, or don't repack [14:05] (otherwise nobody else knows what's going on) [14:06] well, at the moment im using a manual script that runs and automates all these steps, (including downloading the source, repacking, and executing the pbuilder stuff) [14:06] should i really be shifting all that inside the actual debian rules? [14:06] as it's a 3rd party thing maybe not. but for anything in the archive, I'd strongly suggest doing so - it's what people expect [14:07] got it, yeah that makes sense because renaming a dir or moving a dir is just the same as making a change [14:07] we all have our own workflows for doing most of the things you mentioned [14:08] and moving the dir struct without tracking it in the package, is just the same as making a change to the source instead of using a quilt patch, right? [14:08] (i.e. if someone wanted to modify the package without this bootstrap script, its break) [14:08] exactly [14:09] makes sense - ty for the advice :) [14:25] just found a good example of that method i think; http://anonscm.debian.org/viewvc/python-modules/packages/python-gd/trunk/debian/rules?revision=20305&view=markup [14:26] seems clean [14:26] yip, that's what I mean [14:27] something that does confuse me slightly.. where is get-packaged-orig-source invoked?? i couldnt find any other mentioning of that name in any of the other files [14:27] it'd be run by hand [14:28] ahh [14:28] make debian/rules get-packaged-orig-source ? [14:28] (bzr-builddeb knows how to run it, too, if you keep your package in bzr) [14:28] yes [14:28] got it, so could just throw a Makefile into the root dir above debian/, and have make builddeb, that would execute the get-packaged-orig-source, and the pdebuild.. sound clean? [14:31] no [14:31] dh will see that makefile and try to use it [14:33] even if its one dir above the debian dir? i.e. [14:33] - / [14:33] - /Makefile [14:33] - /debian/rules [14:33] oh wait, of course [14:33] that's where makefiles usually live :P [14:33] haha yes, *doh* [14:33] this sounds like it's a personal script, it's nothing to do with teh package [14:34] yeah, just a convinience script.. which should be kept outside of the package, right? [14:34] (or at the very least, in another dir above that one [14:35] yeah [14:35] i gotta admit, this is all starting to look a lot cleaner now.. 90 degree learning curve, but its really quite nice [14:36] a lot of those "wtf is this for" moments are now "ahh yes, now i see" [14:36] good ogood [14:37] make that, good good [14:41] sorry, design question.. if the download stage relies on some messy shell script and python script.. is it acceptable to place those scripts into a subdir of the debian/ dir, and then call them from the debian/rules file? [14:42] (in this case, a python script fetches the most recent release URL, then a shell script does a curl download and repacking) [14:44] sure [14:44] ty [14:44] if uscan can't do it [14:44] uscan.. *googles* [14:45] oh nice.. tho im not sure it would be compatible.. atlassian expose a malformed JSON file, which has to be mangled and parsed to find the appropriate release URL [14:46] d = f.read() [14:46] d = json.loads(d[10:][:-1]) [14:46] d = filter(lambda x: x['platform'] == 'Unix' and x['type'] == 'Binary', d) [14:46] v annoying [14:46] right [14:58] hmm i just thought, developers would most likely want the ability to specify the package they are about to compile... so it would make more sense to make this a configurable.. [14:58] the most sane approach for that would be to include a ./configure script right? [14:59] i.e. ./configure; askes them for the version they wish to compile against, the configure script then stores this version number for the Makefile to use during make [14:59] foxx2: the get-packaged-orig-source you pointed at figured out the version you want from looking at debian/changelog [14:59] (slightly off-topic from packaging) [14:59] ahhhhh [14:59] okay yes, now i see, so they just modify the changelog version number and it takes care of itself [15:00] perfect, ty === lynxman_ is now known as lynxman [15:55] hmm, is it normal for "quilt push -a" to have a return code of "2" even if it was successful? [15:56] see "EXIT STATUS" in quilt's man page [15:57] hmm, i dont seem to have EXIT STATUS in my man page :X lemme google sec [15:57] checked 3 different sources for man quilt, nothing mentioning exit codes or exit status [15:58] lol - https://lists.gnu.org/archive/html/quilt-dev/2013-01/txtJTixiCUfQ7.txt [15:58] that'd be why [15:58] only added in january :X [15:59] there we go, that explains what exit code 2 is.. ty :) [16:00] wha [16:01] gotta love reading documentation from patch files on dev trunk.. lol [16:01] xnox: how come when I go to http://manpages.ubuntu.com/manpages/raring/en/man1/quilt.1.html I get redirected to .../precise/... (that's what happens if the release isn't found, for example 's/precise/laneyrules/') [16:01] did oneiric and raring not get generated correctly? [16:04] Laney: no idea. I only did a monkey patch, I may have gotten it wrong. And all I did was ask IS to deploy this and hope it works. I am not aware if there are funky deployments instructions to go with suite updates. [16:04] BLAST! [16:04] kirkland: ↑ this is yours IIRC - can you help us? [16:04] * xnox wonders if they are generated only once on deploy, as they previously were always generated post-release. [16:05] lol did i just open a can of worms? sorry :X [16:05] and hence are not cronned to be kept up to date? [16:05] oh, fun so we'd have 2 years outdated manpages :) === mapreri_ is now known as mapreri === jbicha_ is now known as jbicha [17:33] oO new mails in-devel 205 since yesterday? not even the worst threads on dd managed that :O [17:34] heh [17:34] no, I think mail from lists.ubuntu -> gmail jammed up a bit [17:34] you should try ubuntu-users [17:34] all the gmail users seem to have been complaininng, but there was actually very little discussion today [17:34] at good times 300/day are normal there [17:39] I finally got the mail that started all [17:39] I wonder why it was delayed so much [17:39] you are not the only one it seems [17:39] someone complained last night too [17:39] presumably because the ubuntu lists have been fairly idle in recent months [17:39] * ogra_ had all of them on time [17:39] oh its l.u -> gmail, not other way round [17:39] gmail rate-limits source IP addresses [17:40] yeah, you guys were missing out on the fun [17:40] Laney: howdy ... looking [17:41] and thunderbird marks the mail as scam :) [17:41] it's all part of the big Canonical conspiracy to pretend to have important conversation in the open ;) [17:41] naah, it's all your fault for using proprietary e-mail services :P [17:42] is there a good free one? [17:42] good question, probably not [17:42] * tumbleweed runs his own [17:57] why did I add adt tests to all my stuff, now I actually have fix all the breakage ._. [17:58] :P [17:58] out of interest, how do you know they broke? [17:58] from the jenkins instance [17:59] * tumbleweed finds running adt-run ultra-painful, and I don't go looking at that jenkins often [17:59] I have a more lightweight script [17:59] quite easy to use [17:59] using chroots [17:59] share? [18:00] its super ugly :) [18:00] in that case, make it beautiful first :) [18:00] maybe I should write myself one... [18:00] http://paste.ubuntu.com/5585766/ [18:01] sadtrunner.py

[18:01] multiple test handling is not perfect it just installs all deps [18:01] also no restriction handling [18:01] that's not *super ugly, it seems sane [18:01] look at the handling of stderr :) [18:01] yeah, I'd be quite keen to run each set of tests in its own chroot [18:01] *each test [18:02] I wanted to just remove the dependencies and run again, but didn't get it right on first try and haven't tried again [18:02] there are probably still some remnants of the try in there [18:13] why does python-imaging in experimental behave different than raring? [18:13] Image.open("/usr/share/pyshared/scipy/ndimage/tests/dots.png") gives mode P, in debian it gives RGB [18:14] no relevant diff it appears, strange [18:16] possibly because the image is compressed different in ubuntu? [18:18] indeed [18:18] nice [18:28] oh, on the samples? [18:28] that'd make sense [18:40] anther issue found only by autopkgtest :) [18:44] having a bit of trouble with pbuilder if anyone has a moment.. google fails me again.. seems to be an issue getting dependancies to work inside pbuilder.. see http://pastebin.com/seCdFU11 (at the bottom is the debian/control file, at the top is the pbuilder output) [18:45] foxx2: why do you want ia32-libs? [18:46] foxx2: if this thing is 32-bit only, just build it on i386 and be done. The i386 package can be installed on an amd64 machine thanks to multiarch [18:47] ohhhh [18:47] DIST=squeze ARCH=i386 pbuilder create - is that right? [18:47] it looks like your pbuilder chroot didn't have i386 available as a foreign architecture (which is quite sane) [18:48] yeah, for the common pbuilderrc [18:48] except that squeeze doesn't support multiarch [18:48] oh [18:48] your pastebin was a of a sid chroot [18:49] I recommend use DIST=stable using names may cause cachers to collect data forever [18:49] if i use ARCH=i386 DIST=stable to compile the package, i can still install the package on a squeeze distro right [18:50] no, squeeze predates the multiarch work [18:50] what I mean is, you can't istall i386 packages on amd64 squeeze installs [18:51] got it.. so id have to somehow make my amb64 pbuilder environment work with the ia32-libs dependancy? [18:51] yeah [18:51] which it probably will for squeeze, but won't for sid [18:52] im assuming that means ive gotta manually fudge the /etc/apt/sources.list in the chroot?? [18:53] no [18:53] I suspect your package will build as-is on squeeze amd64 [18:54] oh so i should remove ia32-libs from the deps? the app fails to run without it installed though [18:54] I'm saying the opposite [18:55] on squeeze, I think it's fine as-is [18:55] on sid, build on i386, not amd64, and avoid the whole ia32libs thing [18:55] ohhh, wait sorry i just re-read the convo again (brain is dying) - i understand now.. ill give that a try, ty :) [18:56] im not sure how ive ended up with a sid chroot.. i must have made a typo somewhere === shadeslayer is now known as evilshadeslayer [19:21] hm I still get these strange bus errors in raring chroots [19:21] am I still the only one? [19:21] (cowbuilder) [19:23] Hmm, I seem to be getting a bunch of ubuntu-devel mails from 3 days ago in my inbox :/ [19:23] Is that happening to anybody else? [19:23] lfaraone: not only you [19:23] all gmail users [19:28] pbuilder broken too [19:35] pbuilder is broken on gmail? [19:35] * ScottK is confused [19:36] that was related to a earlier line :) [19:36] my raring pbuilder/cowbuilder chroots on raring and quantal for some reason don't --build anymore [19:36] since about a week [19:37] other dists work [20:19] tumbleweed: yeah fixing the distro so it was squeeze instead of sid seems to have fixed the problem. ty :) [20:27] jtaylor: It was funnier my way. [21:13] is there a recap of what I have to do to be able to participate at the uds? [21:14] irc + a audo webcast is probably not happening this time? [21:16] irc + youtube [21:17] regular anonymous youtube is enough? [21:17] * jtaylor does nto even know what this hangout is which keeps getting mentioned [21:17] should be [21:17] good [21:17] only a few people can participate in the hangouts [22:13] 10 [22:34] lfaraone: Since you're interested in AFS, you might want to read DSA-2638-1 and then prepare patches for an Ubuntu security upload. [22:39] ScottK: Sure. === evilshadeslayer is now known as shadeslayer