Hello everybody,

I'm happy to announce that release 2.0.4 is
finally out, bringing you lots of fixes and some
enhancements over the previous officially
released versions. I hope you'll enjoy the
release, special thanks go to all of you who
helped us with their all kinds of contributions
(bug reports, patches and release candidate
testing).

Greetings

Tomas
(on behalf of the whole FPC team)

Thank you very much, I was waiting for the release of 2.0.4 so I could compile .DEB packages for Ubuntu Dapper as I had previously compiled the 2.0.2 release for Ubuntu for people to download. I just found out that there are now official .DEB packages so it will no longer be necessary for me to build them, great stuff.

It would be nice to see 64 bit .DEB packages downloadable too, in the future maybe. I think .DEB packages are very important to support, since Ubuntu is now one of the top Linux distros.

Op Tue, 29 Aug 2006, schreef Rob van der Linde:

.deb packages will only be available if there are volunteers to build them. There were for i386, but not x86_64.

One problem with .deb packages (and also with .rpm) is that one needs a full Latex installation on his system in order to be able to compile the documentation. With .tar this is not necessary, because people who build a package can use a pre-built documentation set.

The result is that most people who maintain a platform choose to build .tar only. Of course, another point is that not everyone in the team uses Debian or a Debian derivate. The x86_64 release was built by someone who uses SuSE.

Daniël

Yeah I am aware you need a full Latex install, because I built Free Pascal 2.0.2 about a month ago in Ubuntu Dapper (32-bit) myself, and put the .deb files up on the Ubuntu forum for people to download. Even with still fairly limited Linux knowledge I found it quite easy to build however, even installing the Latex environment, although I had never done this before was a breeze.

I would love to be a maintainer and build .deb files, however I do not own a 64 bit CPU and can't afford one at the moment because it would also mean a new motherboard and RAM too, so that crosses me out pretty much. In fact, I really would love to see Free Pascal packages in the Ubuntu universe repositories in the future.

Hi,

i'm using debian unstable (amd64) and build the deb's always for me. I have uploaded them now to my private homepage [1] for download.

greetings
kisda

Sorry :
http://homepage.hispeed.ch/kisda/

the source package is already there. The problem is that the autobuilders can't build it (because of the recursive build dep issue) and there seem to be very few people who have permission to upload manually built packages in ubuntu.

IMO it would be a good idea to restructure the debian packaging of fpc to include starting compilers as part of the source. What do others think?

Hi,

my 2 cents:
Im quite happy with the current packaging. svn update && make deb and it builds fine. I think the main target should be that debian ships always an uptodate freepascal compiler. The current state is very good, the freepascal repository contains the debian files and everything is at one place, so to upload a new freepascal version to debian there are no changes needed. Simply checkout, build and upload. (There is currently one issue, see below [1])

If you start to put binary files in the freepascal source, you can't use this for debian. As a consequence, the debian build of freepascal and the freepascal's deb build would need two different sets of debian packaging files and I would bet that this doesn't help to have actual freepascal version in debian/ubuntu.

For the recursive build-dep. This is a onetime issue. The maintainer needs once to make a binary upload and not only a source upload. After that, your build-dep is satisfied. It has worked for debian for years, why should't it work for ubuntu?

[1] The current issue:
Until freepascal 2.0.4-rc3 the deb build worked as it should, but with the the final release is fails. The reason was the missing libgdb binary. So I downloaded it and it worked again, but it should work without it. There was a commit to fixes_2_0 after the release of 2.0.4, which tries to call COPYTREE libgdb in the debcopy target only if the directory is found, something like [ -e fpcsrc/libgdb] was inserted, but it still fails, because it returns false if it doesn't exists and "make" thinks that something has failed.

thx
kisda

On 29 Aug 06, at 18:46, Rob van der Linde wrote:
.
.

As a general comment, we always welcome people
interested in supporting release builds (and
preferably at least occassional snapshot builds
too, so that problems with particular platforms
are discovered earlier). This is true even for
platforms which can be supported by existing core
team members at the moment (like 32-bit .deb
packages). Release building for every platform
needs some effort and time which can better be
invested to FPC development (not even talking
about need for backup if someone having access to
a particular platform is currently too busy, on
holiday, has broken machine, etc.). Any
volunteers are welcome to contact us here in the
list or send me a private e-mail (I'll talk to
Stefan and Rob in the meantime directly to check
how serious their interest really is ;-) ).

Tomas

Stefan Kisdaroczi wrote

peter green schrieb:

.
.

Thanks for this feedback, we'll try to fix it.

Tomas

For the recursive build-dep. This is a onetime issue.

This is making the rather uncertain assumption that each version can be built with the last (not true with all 1.9.x versions though maybe more effort is being made post 2.0.0).

the problem is that ubuntu has a general policy against binary uploads (because it ensures that the packages can indeed be built on systems other than the maintainers private system). Only very few people seem to be able to override this and those people seem very busy and not to really care when i ask them to do it for freepascal.

Op Tue, 29 Aug 2006, schreef peter green:

It is guaranteed that a release can be built with the last stable release, which, in the case of 1.9.x was 1.0.10. I remember 1.0.6 worked as well.

With 1.9.x, allowing old 1.9.x to compile new 1.9.x would have required a lot of ifdefs at that time (we were changing calling conventions). There were already a lot of ifdefs for 1.0 compatibility and we weren't happy to add another set. It was decided that stick to the "last stable release" policy and therefore support 1.0 as bootstrap only.

In general, if it is no problem, we avoid breakage. At this time 2.0.0 can still compile all releases and branches.

Daniël

peter green wrote

> For the recursive build-dep. This is a onetime issue. This is making the rather uncertain assumption that each version can be built with the last (not true with all 1.9.x versions though maybe more effort is being made post 2.0.0).

FPC policy is that that the latest
official/stable release should always compile the
following release(s). 1.9.x were betas, not
stable releases, so everything up to 2.0.0 was
compilable with 1.0.10 as the latest official
release at that time.

Tomas

peter green wrote

the problem is that ubuntu has a general policy against binary uploads (because it ensures that the packages can indeed be built on systems other than the maintainers private system).

I think that this is the case for all distributions.

Only very few people seem to be able to override this and those people seem very busy and not to really care when i ask them to do it for freepascal.

If they're not interested enough in helping other ppl around, why should you use their distribution? ;)

Just beg, harrass and try to convince them.... If it's done once, yo'll never need them again...

Hello,

Might I sujest that it would be great if someone build DEB packages for Lazarus =)

Personally I use Mandriva (rpm based), but I see lot´s of people with install issues with Lazarus because of the lack of deb packages.

There are some files to build a package on subversion. I´m not sure if they are compile.

Only for new cpu targets a manual upload is needed. The debian buildd's work fine with current .deb. They install the latest available fp-compiler and can then build the new .deb.

Come on, the linux package systems are stupid and stupid systems can be fooled. One can provide a fpc bootstrap package containing precompiled assembler files which are assembled when built.

That's what I would recommend nvidia for years: provide their drivers as assembler files. Nobody can proof that it is actually compiled and they don't release more knowledge than they actually do and the gpl trolls can't flame anymore :)

Florian Klaempfl wrote

That's what I would recommend nvidia for years: provide their drivers as assembler files. Nobody can proof that it is actually compiled and they don't release more knowledge than they actually do and the gpl trolls can't flame anymore :)

Nobody will believe they hand-code, maintain and extend the source in assembler form.

Micha

Believing and proving is something different :)

Op Wed, 30 Aug 2006, schreef Florian Klaempfl:

That's what I would recommend nvidia for years: provide their drivers as assembler files. Nobody can proof that it is actually compiled and they don't release more knowledge than they actually do and the gpl trolls can't flame anymore :)

Nvidia's used a source code obfuscator to submit their first driver to XFree86. Needless to say people weren't amused with it. It was originally put in cvs but kicked out after a few weeks. Then Nvidia backed down and released the non-obfuscated source code.

Apparently they were far from happy with that, since they never released source code ever again.

Besides, assembler source code would release a lot of info, such as the names of the GPU registers, which would make it much easier to understand their function.

Daniël