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