=== warthylog [~warthylog@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-java === Topic for #ubuntu-java: Java status in Ubuntu: gij-4.0 now works across all arch's. See http://wiki.ubuntu.com/JavaPackagingProgress for next steps, JavaIntegration for goals. | 3.1M7 has pretty much everything we expected. Performance improvements are surprising, however. For example, launching a workspace containing all Eclipse SDK sources used to take close to 2 minutes in 3.1 M6. It now takes under 10 seconds. Good job, guys. === Topic (#ubuntu-java): set by jbailey at Mon May 16 03:32:39 2005 [12:25] ok.. logs will be available from now on... they will start appearing on the server in not less than one hour [12:25] enjoy :) === fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has left #ubuntu-java [] === jbailey [~jbailey@CPE00501836c657-CM014260028338.cpe.net.cable.rogers.com] has joined #ubuntu-java === doko [~doko___@dsl-084-059-062-132.arcor-ip.net] has joined #ubuntu-java === wasabi_ [~wasabi@207.55.180.100] has joined #ubuntu-java [05:30] So, 3.1 really isn't that much better. [05:30] Basically they just moved stuff around and introduced a whole new set of packging problems. [05:35] Hey. Should .db files be put into share or lib by packages? [05:36] I'm about to actually start using this stuff for real packages. [05:47] Lemme check FHS [05:47] Hold on, the db files? [05:48] Not the .so files? [05:48] .so files should be in /usr/lib/... [05:48] db files are generated at install time, right? [05:55] Nope. [05:56] The .db files will be distributed in each package and put into a central dir. [05:56] And the postinst will regenerage the main db file in /var/lib [05:56] regenerate [05:56] /usr/share/gcj-4.0/classmaps.d/packagename.db or something [05:56] I am uncertain if that should be in /usr/share or /usr/lib though, as it refers directly to .so files. [06:00] The best thing is to generate one on two different arch's and see if they're exactly the same. [06:06] Check #gcj on OFTC. [06:06] Interesting point. [06:06] How do we deal with multiarch? === estragon [~estragon@ANice-252-1-81-253.w83-201.abo.wanadoo.fr] has joined #ubuntu-java [09:42] jbailey, converting Eclipse to cdbs. Need some assistance. [09:43] I have a fairly elaborate "configure" step. [09:43] configure:: prepare-stamp should make cdbs call my prepare-stamp target right? [09:43] Just using debhelper.mk.... [09:44] Oh I guess that should be pre-build? [09:50] pre-build is probably the best choice if you can. [09:50] I need to know more about what you're doing to guess properly, though. [09:50] extracting the source, applying patches. [09:52] There's a target apply-patches:: you can use. =) [09:52] Is that part of debhelper.mk? [09:53] I can't use a built in patch system. [09:53] Nope, it's part of buildcore [09:53] Since I have a custom one that works per eclipse plugin [09:53] okay cooll [09:53] Does this thing manage stamp files? [09:53] No. =( [09:53] Eclipse takes so freaking long. [09:53] That's a major deficiancy in cdbs atm. [09:54] I have it split into a bunch of pieces just to make debugging easier [09:54] I think I'll just hang my current stuff off of it then. [09:54] Probably best. [10:06] Heh this is odd. [10:06] I have these packages: [10:07] eclipse-sdk and eclipse-platform and a bunch more. [10:07] eclipse-sdk is Arch: all. [10:07] eclipse-platform is arch: any [10:07] Hmmm. I need the build process to happen before either are installed. [10:07] Right now it looks like it's trying to do arch indep stuff first, before it goes down my build process. [10:08] I would have expected build/eclipse:: to happen before any package, arch dep or indep. [10:08] Maybe I'm not using build/eclipse right. [10:09] How do I add a build target that is required for ALL packages? [10:14] You're crawling into the cobweb ridden corners of cdbs here, and alot of the motivation for cdbs2. =( [10:15] hehe. [10:15] (And stuff tha tI have to look up to get right, justasec) [10:15] common-build-arch:: might be a good choice. [10:16] Ah. [10:16] Honestly, I avoid the PASS/PACKAGE stuff as much as I can. [10:16] -indep stuff too? [10:16] It was a neat idea implemented poorly. [10:16] Yup, it's there. [10:16] Although in practice -arch is fine. [10:16] I like it. If nothing else it lets you seperate code easier. [10:16] It's always called. [10:16] Right, except that people don't build their packages cleanly along the lines of their packages. [10:17] and provides a bit of self documentation [10:17] cdbs2 introduces build passes that you can name explicitely. [10:17] And packaging passes that are based on the package names. [10:17] Still didn't work. [10:17] common-build-arch:: build-eclipse-compile-stamp build-eclipse-install-stamp [10:17] common-build-arch-indep:: build-eclipse-compile-stamp build-eclipse-install-stamp [10:17] But neither of those were called before debhelper started running for eclipse-sdk [10:17] common-build-indep [10:18] There we go. [10:18] This does help. It makes the code easier to follow. [10:19] How about a recommendation on how to "install" eclipse. Which steps go where? Right now I have the build targets building the eclipse.tar.gz file [10:19] That's how the eclipse upstream build system works. It ends up with a tar.gz [10:19] Then, in the install portion I "install" the .tar.gz to debian/tmp. [10:19] Basically just extracting it. [10:20] But then I have to move lots of pieces between different packages... and take debian/extras, shell scripts and stuff, and put them in the right place. [10:20] Should I be installing the extras into debian/tmp and then relying on dh_install to move them to the right package? [10:20] Well, dh_install can reach into the debian/extras directory directly. [10:20] So there's no need to move them to debian/tmp first. [10:21] But then I have some which require preprocessing [10:21] like debian/extras/eclipse.png.uu [10:21] Right. Can you do those in the build phase somewhere? [10:21] Is that what's proper? [10:21] Move those into tmp. [10:21] I like to do all munging and such in the build phase. [10:22] It means that if I stamp that off, I'm done. I don't have to waste time doing any munging again. [10:23] sounds good [10:24] So build the .pong in build, but don't copy it to debian/tmp until install (where it's handled by dh_install) [10:28] Right. That means that you can always blow away debian/tmp and just redo the build from install. [10:28] Probably nice in the case of eclipse. [10:28] oh yes. [10:28] heh. [10:28] it's a 30 minute compile. [10:28] Ouch. =) [10:28] It uses about 900MB of space. [10:29] During build. [10:29] We use tricks like that for the glibc build. [10:29] When working on packaging, you *Really* don't want to have to rebuild it. [10:29] How much of eclipse is C/C++ code? [10:29] Very little actually. [10:30] Ah, too bad. [10:30] Otherwise ccache might have sped the build up somewhat. [10:31] yeah. =( [10:39] can dh_install move files? [10:39] Like, I want usr/share/eclipse/eclipse to be moved to usr/lib/eclipse/eclipse [10:39] and then use dh_link to link it back [10:40] Dislike managing that stuff manually. [10:45] Umm. [10:45] I don't think it can. [11:50] make confuses me [11:50] common-install-arch:: install-eclipse-stamp [11:51] yet when I run debian/rules common-install-arch, it repeats it. [11:51] even though install-eclipse-stamp exists