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