[11:10] <biri> hey
[11:11] <biri> if i click BUTTON(name 1) it write to textField 1
[11:11] <biri> how can i do this
[11:14] <nthykier> biri: You should ask in ##java, we cannot help you with java coding here
[23:10] <mpontillo> So, what's the packaging strategy for something like pydev? (Eclipse plugin - http://pydev.org) I notice Debian sid has a package for it, but it's very out of date.
[23:11] <nthykier> mpontillo: What do you mean with what the packaging strategy is ?
[23:12] <nthykier> mpontillo: We could definitely use an extra hand with maintaining eclipse sub-packages if that is what you are asking
[23:13] <mpontillo> nthykier: Well, it doesn't seem like a lot of third-party eclipse plugins are being kept up to date. I was wondering what the expectation was - if users were expected to install plugins themselves.
[23:13] <nthykier> (or just eclipse itself for that matter)
[23:13] <mpontillo> right - I might like to try my hand at fixing a few. Not sure where the right place to fix them is though; I assume fix them in Debian and then sync them.
[23:14] <nthykier> mpontillo: There is an interest in getting them updated, but we lack both resources and experience so currently it is taking a while
[23:15] <nthykier> mpontillo: Yeah, fixing them in Debian is the solution here. Currently build tools for eclipse sub-packages exists only in Debian
[23:16] <mpontillo> nthykier: are there any up-to-date packages for Eclipse plugins that I can take a look at, for an example to learn from?
[23:16] <mpontillo> I checked the obvious one - eclipse-jdt, but that's just a binary package built from the eclipse source ;)
[23:17] <nthykier> mpontillo: http://git.debian.org/?p=pkg-java/eclipse-emf.git is probably the best example we have. It is not uploaded yet and not even tested.
[23:18] <nthykier> mpontillo: But I believe it is our most up to date package (packaging wise) ; we based it on Fedora's packaging of the same sources
[23:18] <mpontillo> looks like the gist is to install things into /usr/lib/eclipse/plugins, but I lack a complete understanding of how this works. let's say I install eclipse-jdt, and that installs some core, required components
[23:19] <nthykier> actually eclipse (and eclipse-jdt) needs to be checked and probably move most of that cr*p into /usr/share/eclipse/plugins, but yeah
[23:19] <mpontillo> now the user comes along and installs cool-plugin-1.0, which depends on a newer version of one of those core components. so the eclipse updater goes and downloads it. I'm assuming the newer version gets installed in their ~/.eclipse somewhere - do we have to worry about corner cases here?
[23:20] <mpontillo> I guess Eclipse is smart enough to look in both ~/.eclispe and /usr/lib/eclipse and find the most recent version of everything?
[23:21] <nthykier> eclipse does not allow users (by default at least) to "upgrade" the base installed plugins (anything from eclipse-platform, eclipse-rcp, eclipse-jdt, eclipse-plugin-cvs or eclipse-pde); so that is not a problem
[23:21] <nthykier> I believe it is
[23:22] <nthykier> I am not sure if eclipse's "no upgrade of base plugins" extends to these extra plugins (like the eclipse-emf package)
[23:24] <mpontillo> ah - and /usr/share/eclipse/plugins, thanks - hadn't seen that. I notice the git repo you linked makes a reference to /usr/share/eclipse/dropins/ as well?
[23:25] <nthykier> mpontillo: yes, currently anything not built from the eclipse source package will be dumped in dropins
[23:27] <nthykier> We may change that based on what upstream does though
[23:28] <nthykier> which is one of the reason that we have helper tools for this :P
[23:33] <nthykier> mpontillo: Again, you are more than welcome to join us. The team consists of 3 active people (bdrung_ is one of them).
[23:34] <nthykier> mpontillo: If you want commit access, you need an account at http://alioth.debian.org/ and join the pkg-java team (just mention that you are there to help package eclipse stuff and you will get through).
[23:35] <nthykier> Most of our packaging coordination takes place in #eclipse-linux or #debian-java (on irc.debian.org)
[23:35] <nthykier> per IRC that is - we also have a wiki page.
[23:36] <nthykier> mmm, we haven't imported eclipse-pydev yet to the git repositories... we should get that fixed as well
[23:36] <bdrung_> yeah, eclipse-cdt and eclipse-pydev
[23:37] <nthykier> bdrung_: eclipse-cdt is imported already
[23:37] <nthykier> Just not fixed at all :P
[23:47] <mpontillo> nthykier: thanks, I'll get set up. not sure how active I can be, as my spare time is limited - but I'll do what I can.
[23:48] <nthykier> mpontillo: awesome; feel free to ping us if you have any questions.
[23:49] <bdrung_> mpontillo: ping nthykier ;)
[23:49] <bdrung_> nthykier: :P
[23:50] <mpontillo> nthykier, will do. I guess my first order of business will be getting a Debain development environment set up. I have Ubuntu Lucid running on this laptop; what are the best practices? should I go grab a Debian ec2 instance?
[23:51] <nthykier> a sid chroot should be enough - personally I use cowbuilder for it
[23:51] <mpontillo> thanks, will check it out.
[23:51] <nthykier> I believe Ubuntu has a guide for setting up a sid chroot with cowbuilder/pbuilder, though I cannot remember it off hand
[23:52] <mpontillo> Yeah, I have set up pbuilder before. I'm sure I can find it.
[23:53] <nthykier> awesome ...
[23:53] <mpontillo> weird, why does alioth make me append -guest to my username?
[23:53] <nthykier> because it auto imports DD usernames, so to avoid conflict non-DD members got a -guest suffix
[23:54] <mpontillo> ah. gotcha
[23:56] <nthykier> Okay - I am off for today.
[23:57] <mpontillo> thanks for the help
[23:57] <nthykier> Thanks for considering to join the effort
[23:57] <mpontillo> np.