Ubuntu Packaging

[Ademan]

Hi,
   I'm totally new here, but I love your IDE.  I'm an Ubuntu user and I love my linux distro as well.  I've been looking for a packaging project so that I could give back to my distro.  What better way to do that than package Code::Blocks?  To better serve the Ubuntu community I would be packaging Code::Blocks and uploading it to the universe software repository (which implies that it is being redistributed)  I would like your (The developers behind this great project) blessings to upload them to the ubuntu repositories.  Also any help, advice, or requests you have for me would be welcome.

cheers
-Dan

P.S. I wasn't quite sure what topic this should be so I chose general, feel free to move it.

[mandrav]

First of all, welcome Ademan .

Yes, we plan on submitting codeblocks for inclusion in ubuntu repositories. But we want to have a stable release first.
As for who should be the packager, that's open for discussion. Volunteers are always welcomed .

FWIW, I 'm the one who created the debian/ dir. Actually I have modified it but haven't committed my changes yet. Modified it to create the following packages:

codeblocks
codeblocks-contrib
libcodeblocks
libcodeblocks-devel
libcodeblocks-dbg


Regarding who is "responsible" for the debian/ dir, if we find ourselves a maintainer, he will be granted commit access to the debian dir in our repository. Unless you mean something else. If so, please clarify.

Yiannis.

[Ademan]

First of all, thanks :-)

As far as packaging, I think their question was regarding actually having the debian/ dir part of your sources more than anything, I guess it raised some sort of legal issue in the even we needed to modify it? (I'm no expert on the GPL or any of the licenses for that matter) Or just as likely it's a sort of idealistic problem for them, they did mention it might be a bit messy if an ubuntu guy has to modify an existing debian/ directory.

But really that was less of my main point (that's why i edited it out :-) )

That's great to hear about you guys wanting it in ubuntu.  I'm not sure if you're familiar with the schedule of Ubuntu releases, but they have both a "Feature Freeze" and an "Upstream Freeze" coming up February 8th for Feisty.  https://wiki.ubuntu.com/FeistyReleaseSchedule  My understanding is if they don't have the package by then it CAN'T be in Feisty, which I'd love to see.  On the other hand, I totally understand your concern about an unstable SVN checkout being in the repositories (some people could try it and get discouraged because of instability or something like that, of course it could be patched to warn the user)

And as far as a package maintainer, I'd love to do that for you guys, however, unfortunately as of now, Code::Blocks was going to be my first package ever. (In other words I'm no good ... yet :-) )  I've checked out the sources from SVN and i'm going to study the debian dir, as I've done for a few other packages.

Of course, even if you thought it would be ok to put a development snapshot in the ubuntu repositories, there's a question of whether Ubuntu's package reviewers would be ok with that, which I'm looking into.

EDIT: I've talked to some of the packagers and they say that unstable SVN snapshots are not unheard of in the ubuntu repositories, and if it's more stable than the previous release, "then go for it"

Thanks,
Dan

[Ademan]

Well, I don't know if anyone's tried building a debian package from the SVN, but I've been trying.  I'm not having much luck, but as i've said before, this is my first package, and so i'm by no means an expert... My first question is this:

pbuilder downloaded g++ 3.4  Why 3.4?  Why not something newer like 4.1?

And second, in debian/rules   config.status depends on the target configure, which doesn't exist. I'm currently editing it just to see if i can get it to work.  Heh, I just picked up on something, there's a lot of code in the debian/rules missing :-)

But anyways, I guess I still would like to know if you're OK with me packaging up Code::Blocks for ubuntu's next release.  I guess technically I could no matter what since it's GPL(it is right?), but I don't want to do it if you don't feel comfortable having something unstable representing you in ubuntu, I have yet to try the version from the SVN, but I assume it is every bit as good if not better than the other IDE offerings on linux.

thanks
-Dan

[mandrav]

And second, in debian/rules   config.status depends on the target configure, which doesn't exist. I'm currently editing it just to see if i can get it to work.  Heh, I just picked up on something, there's a lot of code in the debian/rules missing :-)

Well, it's been some time that I have worked on it but IIRC the "configure" dependency is not a target but the "configure" script, meaning that the "config.status" target needs to re-run if "configure" has changed.

With that said, I haven't used pbuilder to create a package yet. The currently provided packages are created with:

Code

fakeroot debian/rules binary

And it builds it just fine.

[Ademan]

hrm, i didn't realize that makefile dependencies referred to actual files, but hey, guess i have more to learn about makefiles as well.

As far as the fakeroot v pbuilder thing, I thought that pbuilder was the correct method, but of course, i may be mistaken again :-/  Anyways I'm working on getting it to package.

By the way, I think i just realized why pbuilder is kind of preferred, because it creates a sort of fake environment (much like fakeroot i assume) where you don't actually have ANYTHING, no packages are assumed to exist, only the ones that are in the debian/control.  Maybe fakeroot does this too, i dunno.  Either way, what about the g++ 3.4 issue?  Someone i asked about it mentioned there may be a problem building with a newer g++, is there? or would it be ok for me to use 4.1?

Thanks for putting up with the stupid questions,
-Dan

[cstudent]

Well I've been building it fine for the nightly builds since last summer. You do realize there is an Ubuntu .deb offered for download in the nightly builds? If you use Mandrav's debian files "as is" then it will want to use g++ 3.4 because in the control file's build depends section it ask for libstdc++6-dev. I actually change this to libstdc++6-4.0-dev and build it using g++ 4.0.3. I also use a chroot environment to build, but I'm not using pbuilder. I use the command `dpkg-buildpackage -D -b -us -uc` to build the .deb. I don't need fakeroot because I am root in my chroot.

I have thought about trying to get Codeblocks into the Ubuntu repos myself but haven't pursued it too much because I, like Mandrav, think it would be best to wait until they (the developers) feel they have a stable release. So I was waiting. I did check into it and saw that someone had tried to maintain a package for Debian in the early part of last year but they didn't do much with it. Plus waiting has given me the time to learn more about Debian packaging and I'm still learning. As far as Codeblocks looking for a maintainer, when they feel the time is right to worry about that, I too would like to put my name on the list of applicants.

Edit: I would also love to get a glimpse of the new debian dir Mandrav if that would be possible. If it's not top secret or something.

[mandrav]

I never said fakeroot is better than pbuilder . I know pbuilder is preferred for the reasons you described.
But fakeroot is easier to use if you just want to get a package out. For packages to enter the official repositories, pbuilder (or chroot) must be used though.

About g++, C::B builds with either version. Make your pick .

[mandrav]

Edit: I would also love to get a glimpse of the new debian dir Mandrav if that would be possible. If it's not top secret or something.

It's not top-secret . I just haven't committed it, although I have it ready since a few months now, just because the current debian dir creates a single package which is easier for users to locate and install (for nightly builds).
I was just saving it for when we would be ready to apply for inclusion in Ubuntu's repositories .

But it you want I could commit the new dir. I have no problem with that.

[cstudent]

No, I think it would be better to wait Mandrav until you are ready to commit the changes. One package to install is much easier right now. Is there some way I could obtain it without you committing it? Like email or ftp? I'm just interested in viewing it and maybe playing around with building the new packages for the practice.

[mandrav]

Is there some way I could obtain it without you committing it? Like email or ftp? I'm just interested in viewing it and maybe playing around with building the new packages for the practice.

Sure. All I have to do is remember to mail it to you from home (where I have it saved) .

[cstudent]

Sure. All I have to do is remember to mail it to you from home (where I have it saved) .

Cool. My email address is in my profile.

[Ademan]

Well, I would like to know if you're ok with having me upload to Ubuntu, despite it not being a release version.  If I was to do that, I'd definitely need the new debian dir (or at least do it myself) because having a single package is easier for nightly builds, but it's not consistent with the ubuntu packaging guidelines, for instance the sdk would be a codeblocks-dev package, etc (exactly like the debian dir you've got).

cheers
-Dan

[Ademan]

Well, one other thing, has your multiple package update made it into SVN yet?  If not I'd appreciate it if you'd send me it because I think i've figured packaging to a large extent, but I'm unfimiliar with single source -> multiple packages.

EDIT:  Here's my email Ademan555@gmail.com

Oh, and one other thing, currently (at least when i built it) the package wants to install all of the shared object libraries into /usr/share.  /usr/share isn't meant to contain any binary machine code (anything architecture dependent really) only things like image files, maybe UI xml files, that sort of thing.  Does it do that on purpose?  Or was it something with how i've built it, since i'm still not certain i've got everything down yet.

cheers
-Dan

[mandrav]

Oh, and one other thing, currently (at least when i built it) the package wants to install all of the shared object libraries into /usr/share.  /usr/share isn't meant to contain any binary machine code (anything architecture dependent really) only things like image files, maybe UI xml files, that sort of thing.  Does it do that on purpose?  Or was it something with how i've built it, since i'm still not certain i've got everything down yet.

In usr/share/codeblocks/plugins we install the plugins, you didn't do anything wrong.