[00:54] is there any supported way to do an automated install of sun java without the licence prompt? [00:54] lifeless: https://wiki.ubuntu.com/JavaTeam/KnowledgeBase [00:55] \o/ [00:55] wikis are wonderful things [00:56] But don't do that unless you *really* must. default-jre and default-jdk are almost always preferable. [00:57] except that there is a bundled and renamed class in sun-java6 [00:57] that isn't like that in openjdk-java6 [00:57] which makes openjdk-java6 buggered for a nontrivial number of apps [00:58] I can dig up the bug # if you like [00:58] http://bugs.sun.com/view_bug.do?bug_id=6876736 [01:02] lifeless: Aha. I'd call that a bug in hudson, but YMMV :) [01:03] hudson, openoffice, ... - depending on what sun shipped for years. [01:03] Well, more deeply, it's probably a bug in Sun, but that's a different matter :) [01:03] could argue it either way [01:03] I'll always argue against code bundling. [01:03] *cough CD image cough* [01:04] * persia wanders off, whistling innocently [01:07] * lifeless waits for hudson to fire off another VM === persia` is now known as persia [20:49] persia: http://rbtcollins.wordpress.com/2010/02/11/using-uec-instead-of-ec2/ is what I needed the sun java workaround for [20:52] lifeless: Cool. I do suggest you add a note that indicates that you should really read the Sun license prior to adding the debconf hint. [20:53] Because adding that is considered equivalent to accepting the license, which is a bit questionable if one hasn't read it. [20:53] (not that everyone reads licenses, but people should at least have to pretend they have done so) [20:53] you should see what hudson (a sun product) does :> [20:53] it just batch installs a copy from s3 [20:54] Yeah, well. [20:54] Something I learned when working with Sun in other areas is that different bits of Sun don't always talk to each other as well as one might hope. [20:55] But I understand that had been improving, although the current news seems to contain lots of uncertainty. [20:56] :> [20:59] Anyway, as with everything else, when wearing "Ubuntu" hats, we do best at helping that integration happen even if upstreams aren't doing it themselves. [21:00] :) [21:01] one can argue that ignoring unenforcable things is a good idea. I'm not sure it is. [21:01] I've added a reply noting that there was some sleight of hand there. [21:02] Yeah, the idea was just to avoid confusion. [21:34] persia: hi [21:34] i just saw that you built swt [21:34] rzr: Yep. [21:34] I am waiting at it to rebuild tuxguitar [21:35] when will it be uploaded [21:35] seems the build is over now [21:35] It's been uploaded. [21:35] * persia checks if it's stuck [21:35] published i mean [21:35] Note: Some binary packages for this source are not yet published in the repository. [21:35] Yeah, it's caught in binary NEW. I'll bug an archive-admin in a bit. Maybe 3-5 hours, if I'm lucky. [21:36] ok [21:36] thx [21:36] last question [21:36] why +versionbump ? [21:37] it's unclear for me [21:37] upstream debian one never went into archive , did it ? [21:38] https://bugs.launchpad.net/ubuntu/+source/swt-gtk/+bug/519994 [21:38] ok [21:38] Ubuntu bug 519994 in swt-gtk "Please unblacklist swt-gtk from the autosync" [Undecided,New] [21:51] rzr: I tried to get Debian synced, but it ended up blacklisted. [21:51] Adding +versionbump let it be accepted, and that bug unblacklists. [21:51] We should be able to be in sync with the next new upstream. [21:52] The issue was just leftovers from when eclipse was providing swt.