=== G_ is now known as G === kentb is now known as kentb-out === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [03:16] Hello folks. [03:27] Any progress on updating Tahoe-LAFS to v1.8.3? [03:27] * zooko checks the ticket === al-maisan is now known as almaisan-away === maxb_ is now known as maxb [05:54] NCommander: It's the .sed.in file. [06:32] NCommander: Are you setting up your own site? [06:58] good morning [07:00] good morning dholbach === ttx` is now known as ttx [07:00] hey philipballew [07:02] announced Tahoe-LAFS v1.8.3: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-September/006675.html === mrpouit is now known as mr_pouit === lool- is now known as lool === chrisccoulson_ is now known as chrisccoulson [11:24] Hi [11:24] where can i get sun-java6 version 24 deb package for 10.04 ? [11:28] where can i get sun-java6-jdk version 24 .deb package for 10.04 ? [12:08] why is https://launchpadlibrarian.net/79858623/buildlog_ubuntu-oneiric-armel.libdecodeqr_0.9.3-5ubuntu1_FAILEDTOBUILD.txt.gz happening (on arm only)? [12:11] Laney: seems to be the same thing afflicting wallch, I wanted to try a local rebuild of opencv to see if it helped [12:11] i saw the wallch report [12:12] * micahg kicks that off now [12:16] \o === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [13:40] dholbach: thanks for sponsoring a patch of mine. do you have any insight on this buildd message? https://launchpadlibrarian.net/79864885/buildlog_ubuntu-oneiric-armel.ethstatus_0.4.3ubuntu1_CHROOTWAIT.txt.gz [13:41] achiang, it looks like something intermittent and related to the buildds, not your fault [13:41] lamont or infinity would probably know [13:41] dholbach: ok, thank you [13:41] lamont was just talkin gbaout it in -evel [13:41] (with correct typing) [13:41] summary: dont worry about it [14:25] not sure if anyone is interested, but debian eclipse 3.7~exp-5 is working correctly on latest ubuntu, if providing libasm3-java 3.3.1-1 and liblucene2-java 2.9.4+ds1-3 [14:25] which is a good thing, considering latest available ubuntu package is 3.5.2... [14:28] lenios: yes, the question is will it build [14:29] i managed to build 3.7~exp4 [14:29] but it needs latest libs [14:30] yeah, those libs are going to be a problem [14:31] asm3 has a lot of rdepends [14:31] yes [14:32] but it needs to be updated, as 3.2-4ubuntu1 is not enough [14:36] lenios: well, that's only if we update eclipse [14:36] at this point, we'd probably have to fork those libs for oneiric to get eclipse updated if that will work [14:41] eclipse will eventually need to be updated, as 3.5.2 is 2 years old [14:42] lenios: yes indeed, but we're a month away from release === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === bulldog98_ is now known as bulldog98 === almaisan-away is now known as al-maisan [16:25] there's probably a reason it is in experimental [16:26] micahg: did opencv finish? [16:27] Laney: no, will probably be another 5-6 hours [16:27] :/ === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [18:31] does beta freeze affect universe? [18:32] * jtaylor wondering if one should sync tahoe from debian incomming to avoid it being hung up in freeze [18:33] only nominally [18:33] as in, launchpad doesn't let you freeze part of the archive [18:33] so it would be better to sync it now? [18:34] doesn't really matter [18:34] hi guys, do you have a suggestion about how to include a "make check" call in a python package being built using cdbs? http://pastebin.ubuntu.com/689417/ [18:34] I tried DEB_MAKE_CHECK_TARGET, but that works only when using the "make" buildsystem, and I was looking for the least intrusive change [18:35] I'm not seeing any good dh_* that I can override, dh_build isn't called [18:35] before dh_install should be fine [18:35] yeah, but how? I see it calling "debian/rules build" [18:35] and then [18:36] dh_testroot, dh_clean and dh_installdirs [18:36] but these are not in the rules file, they are in the included makefiles somewhere [18:36] so, could I override dh_installdirs? [18:37] build/package:: should be the post-install action [18:38] see custom rules in the docs [18:38] cdbs docs? [18:38] ah, cool [18:39] I think I get it [18:39] http://tjworld.net/wiki/Linux/Ubuntu/Packages/CDBSCustomRules found this, I hope it's not out of date, will try some things, thanks [18:43] jtaylor: http://pastebin.ubuntu.com/689425/ thanks, that seems to work fine. Maybe use build/%, although in this case it's really just one binary [18:45] jtaylor: hmm, or did you mean to use binary-post-install? [18:45] * ahasenack tries that one [18:46] I'd run the test before the install [18:46] else you may risk getting some *pcy created in the installation directories [18:46] pyc [18:46] hmm, post-install runs as root/fake-root [18:47] jtaylor: so build is fine [18:49] it's a post-build action === bulldog98 is now known as bulldog98_ === bulldog98_ is now known as bulldog98 [20:44] oh man... [20:44] tahoe maintenance drives me nuts [20:44] completely untested [20:44] the release of debian of course fails 50% of its tests [20:44] as they forgot to patch an egg [20:51] argh the maintainers even "saw" the problem and worked around it (completely not understanding how python dependency resolution works) turning a build failure into a runtime failure [20:51] nice [20:57] jtaylor: that sounds ugly, to say the least === almaisan-away is now known as al-maisan [21:22] jtaylor: Those Ubuntu idiots really don't know what they are doing do they? [21:22] Oh, wait.... [21:22] ;-) [21:23] well the ubuntu package was awful too ... [21:23] at least the natty one (which is still broken) [21:23] Well, plenty of shortcomings to go around. [21:23] I hope the implicit irony tags were apparent. [21:28] unfortunatly I'm also to blame for this error :/ I filed the bug requesting the changed that caused the issue [21:31] jtaylor: we'll get out the tar & feathers for you then [21:52] jtaylor: can you explain the problem in more detail? [21:52] debian problem not related to tahoe [21:53] yes, but I try to keep track of the debian patches [21:53] I asked for the packaging to not depend on the twisted metapackage which pulls in lots of stuff tahoe does not need (lore, mail runner etc) [21:53] arrgh [21:53] twisted in debian is split up in many smaller packages [21:53] did they not see that I commented on that bug warning not to do precisely that? [21:54] so the _auto_dep.py must be patched to depend on what is needed [21:54] you did? even worse the maintainers screwed it up [21:55] * davidsarah finds the link [21:56] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631163 [21:56] Debian bug 631163 in tahoe-lafs "tahoe-lafs: reduce twisted dependencies" [Minor,Fixed] [21:56] hm there is no tac file in the source [21:56] yep, that's the one [21:56] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631163#40 [21:57] "Please hold off applying this change until we've investigated more thoroughly." [21:57] now I'm just irritated [21:57] ah its also autogenerated ... [21:57] yey [21:58] but that can be patched out too [21:58] patching _auto_deps.py is the wrong fix [21:58] the right fix is to undo 631163 [21:58] it wasn't necessary anyway [21:58] but that would mean dragging in all of twisted again [21:58] yes, and? [21:59] this is a security bugfix release [21:59] it shouldn't be making that change [21:59] that change is just a disk space optimization [22:00] please don't patch _auto_deps.py, that will just cause us maintenance hassles [22:01] there does not seem to be more of this in the code [22:02] maybe easy_install.py but that should pull twisted then anyway [22:02] sorry, I don't understand [22:02] note: changing the generation of the tac files will not work [22:03] because we have to be compatible with existing node directories === kentb is now known as kentb-afk [22:03] how does changing a requires change compatibility? [22:04] see http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1159 [22:04] actually just http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1159#comment:18 is most relevant [22:05] these .tac files are generated & end up on the nodes themselves? [22:05] yes [22:05] they are generated when a node is created [22:05] they're cached & not fetched each time, I take it? [22:06] which causes forward-compatibility problems, because changing the code that generates them doesn't change existing nodes [22:06] we probably wouldn't use tac files if we were doing this again [22:06] right, it seems a little brittle [22:06] they're stored in the node directory, and used by twistd (which 'tahoe start' delegates to) when starting a node [22:06] very brittle [22:07] we want to get rid of them, it's just a bit tricky to invoke twistd in the right way without them, which is why that hasn't been done already [22:08] I'd like to emphasize that a security release should not be changing the dependencies [22:08] you not, but debian can [22:08] its called unstable for a reason [22:09] that's something you should take up with the debian maintainers [22:09] (unless that were necessary for the fix, but it isn't) [22:09] er, that isn't my understanding of what "unstable" means in this context [22:09] but yes that change should not make it into oneiric which is unfortunate, more backporting ._. [22:10] I'm confused, what extra backporting is necessary here? [22:11] the 631163 change should not have been made, it's as simple as that [22:11] after your objection yes [22:11] an upstream maintainer (me) explicitly said that it should not be made because it would cause a regression [22:11] blame the debian maintainers for that [22:11] right, that's what I'm doing :-) [22:12] is this the wrong forum to do that? :-/ [22:12] I suppose the bug is the right forum [22:12] I think there is a debian-tahoe mailing list where you can flame them ;) [22:12] yes they should have seen that mail in the bug [22:12] well, I'm supposed to be working on something else [22:12] not only you [22:13] I was hopping to be done with tahoe for now, but then I also expected the debian maintainers to test their apckage before they upload [22:14] sigh, I suppose all I can do is post on the bug for the change to be backed out, then properly tested and re-uploaded [22:14] we have a *very thorough* test suite for a reason [22:14] sorry if it sounds like I'm getting at you, I know this is not your fault [22:14] comment on bug 641649 [22:14] Launchpad bug 629246 in ntfs-config (Ubuntu) "duplicate for #641649 ntfs-config crashed with OSError in __init__(): [Errno 2] No such file or directory: '/etc/hal/fdi/policy" [High,Triaged] https://launchpad.net/bugs/629246 [22:14] in debian [22:15] its partly my fault [22:15] I wanted the change [22:15] right, but the reason for the change not being a good idea was quite subtle [22:15] in principle, reducing the twisted dependency would have been a useful thing to do [22:16] it would have been useful if the nodes didn't have a hardcoded pkg_requires now, but hindsight is a wonderful thing [22:16] yes hardcoded dependencies which can't be reomved is an awful thing [22:17] lets hope twisted does not at some point decide to remove the egg :) [22:18] or renaming it when switching to python3 and abandoning python2 support [22:18] I don't see python 2.x support being dropped by projects for awhile [22:18] tahoe-lafs might need to have some mechanism for updating or replacing the .tac files [22:21] could somebody execute 'locale -a | grep -F .utf8' and give me its output? [22:22] http://paste.ubuntu.com/689561/ [22:22] broder: thx [22:22] I have zh_CN.utf8 in the list, for some unknown reason :s [22:23] ajmitch: we're going to ignore the .tac files, except for looking at the name to detect the node type [22:23] but that's something for a future release, probably 1.10 [22:27] so I'm, off, thx davidsarah for pointing this issue out before it would have caused more even problems === al-maisan is now known as almaisan-away [22:31] no problem, thanks for catching it quickly === tremolux_ is now known as tremolux