License issue: please sync fpc 2.2.2-4 (universe) from Debian unstable (main)

Hi,

bug #260464 is fixed, and the changelog entry says that the package is
safe to sync as Debian has the fixed version, is this not correct? Why?

Please file a separate bug for lazarus. If they need to go in together
then please state that in the bugs.

Also, fpc is a new upstream version, so it may have to get a feature freeze
exception. Is the new upstream bugfix-only?

I'm unsubscribing the sponsors for now, please resubscribe when ready.
I remain subscribed if you have any questions.

Thanks,

James

> bug #260464 is fixed, and the changelog entry says that the package is
> safe to sync as Debian has the fixed version, is this not correct? Why?

I know it says that in the changelog, but I believe (I have not asked
the uploader) that he noted that because I said that I did not have this
problem building in sid. However, I build fpc and lazarus under intrepid
and the first bug that I see was the same as bug 260464. I used the same
patch and the problem was solved. Looking at the code the problem was
not solved in Debian, but I can (at this moment) only guess that it is a
result from different build dependencies. I will try to find out.

> Please file a separate bug for lazarus. If they need to go in together
> then please state that in the bugs.

Ok. I will do that. FPC needs to go in first, Lazarus only after that.

> Also, fpc is a new upstream version, so it may have to get a feature freeze
> exception. Is the new upstream bugfix-only?

I will figure this out tonight.

> I'm unsubscribing the sponsors for now, please resubscribe when ready.
> I remain subscribed if you have any questions.

Ok.

Paul

According to the debian/changelog upstream fixed some things and reworked some problematic elements:
  * new upstream release
    - shlobj changes
    - fix for wince library support
    - fix for windows 64 bit support for >2GB memory
    - Documentation was updated completely to conform to the actual state of
      the compiler and RTL.
    - Possible CodeGear Copyright infringements in the source were reworked
      using cleanroom approach.

So I am not sure if this qualifies for a feature freeze exception.

I filed the sync request for lazarus under bug 276151.

Hi,

I can't find a changelog in the package, however I can see the changes are
pretty big. This doesn't qualify for an autmatic feature freeze exception in
my opinion. I'm preparing the information to request one. It would be good
to know what testing you have done.

I found the following information about the changes in 2.2.1 and 2.2.2:

http://wiki.freepascal.org/User_Changes_2.2.2
http://bugs.freepascal.org/changelog_page.php

Thanks,

James

> I can't find a changelog in the package, however I can see the changes are
> pretty big.

I'm afraid that indeed the changes are pretty big and that because
upstream and debian maintenance are intermixed, the debian package does
not excel in clean packaging. And unfortunately I did not find a clear
changelog, apart from the debian/changelog remarks.

> This doesn't qualify for an automatic feature freeze exception in
> my opinion.

So, I sort of gave up on the idea of getting it into Intrepid, but I am
very willing to help. I just don't know what information is needed.

> I'm preparing the information to request one. It would be good
> to know what testing you have done.

Unfortunately I have not done much testing, except that I use the newly
build fpc and lazarus binaries to build my winff package in my PPA. That
works fine, but than again, the package is pretty simple and small.

Please, if I can be of any help to test or anything, just give me some
idea of what to do. I am also considering of offering help to the debian
packager to get a cleaner package for the future.

Paul

On Fri, 2008-10-10 at 15:14 +0000, Paul Gevers wrote:
> > I can't find a changelog in the package, however I can see the changes are
> > pretty big.
>
> I'm afraid that indeed the changes are pretty big and that because
> upstream and debian maintenance are intermixed, the debian package does
> not excel in clean packaging. And unfortunately I did not find a clear
> changelog, apart from the debian/changelog remarks.

I reviewed the packaging changes, and they seem to be fine. It's the
size of the upstream code changes that I was commenting on.

> > This doesn't qualify for an automatic feature freeze exception in
> > my opinion.
>
> So, I sort of gave up on the idea of getting it into Intrepid, but I am
> very willing to help. I just don't know what information is needed.

I have provided the information that is usually required. If anyone
on the release team needs any more they will ask, and it would be
great if you could find it for them.

> > I'm preparing the info~stevenkrmation to request one. It would be good
> > to know what testing you have done.
>
> Unfortunately I have not done much testing, except that I use the newly
> build fpc and lazarus binaries to build my winff package in my PPA. That
> works fine, but than again, the package is pretty simple and small.
>
> Please, if I can be of any help to test or anything, just give me some
> idea of what to do. I am also considering of offering help to the debian
> packager to get a cleaner package for the future.

Any testing you can do with the updated package would be great. The
perfect test would be rebuilding everything that uses fpc and testing
the results.

Thanks,

James

> I have provided the information that is usually required. If anyone
> on the release team needs any more they will ask, and it would be
> great if you could find it for them.

Thanks.

> Any testing you can do with the updated package would be great. The
> perfect test would be rebuilding everything that uses fpc and testing
> the results.

Last time I looked (several weeks ago) the only package I could find
that depends on fpc is lazarus. The next (hopefully) package that
depends on fpc will be winff. So unfortunately, I can not do much
testing there.

Paul

On Fri, 2008-10-10 at 15:46 +0000, Paul Gevers wrote:
> Last time I looked (several weeks ago) the only package I could find
> that depends on fpc is lazarus. The next (hopefully) package that
> depends on fpc will be winff. So unfortunately, I can not do much
> testing there.

No, that's a good thing if you are correct, as you have tested the
only thing that depends on it and it works with winff, so it's a
positive test of the new version.

Thanks,

James

>Possible CodeGear Copyright infringements in the source were reworked using cleanroom approach.

> So I am not sure if this qualifies for a feature freeze exception.

(I assume this is about 2.2.0 or earlier ->2.2.2 versions, and not within patchlevels of 2.2.2)
The above problems make the only safe license "GPL", ALSO for the libraries which is pretty bad. Please update to 2.2.2 as soon as possible.

Free Pascal core went as far as eliminating all older releases (than 2.2.2) of the site because of this, so it would be pretty bad if Ubuntu stuck to versions that contain the potentially infringing code.

Note also that a new Lazarus release is imminent, and could need 2.2.2.

I meanwhile verified, and Lazarus 0.9.26 will need fpc 2.2.2

hm... there are a number of packages that need fpc (via fp-compiler) as build-dependency, like libhdate, imapcopy, hedgewars, gearhead.

I don't think it's a good idea to make intrusive changes to the toolchain that late in the cycle, so -1 from me.

Looking at upstream changes, there are several core adjustments which would require additional investigations and probably newer upstream versions for it rdepends. Unless you can provide a solid plan to successfully transition interested packages in time for the release (a.k.a VERY soon!), I'd suggest to keep 2.2.0 for now.

Won't Fixing for Intrepid. Should be looked at for Jaunty. If warranted, you might consider asking for a backport after it's in Jaunty.

Note that then the 2.2.0 package should be modified to reflect the changed copyright situation of 2.2.0, e.g. add a prominent notice that it can only be used to make GPL apps, contrary to what the docs say, or wholly retracted the package for a release cycle.

This is the reason why FPC Core has retracted 2.2.0 (and all other previous releases) from its site, and is the main reason for 2.2.2

This also applies indirectly to lazarus 0.9.24 since it uses the 2.2.0 package, while 0.9.26 uses 2.2.2

Something must happen either way for intrepid. Either change 2.2.0 package to reflect the license change as a result of potential infringement, or use the 3 month old 2.2.2 fixes release.

In retrospect, maybe we should have given more of a heads-up after 2.2.2 release, but we thought "POTENTIAL COPYRIGHT INFRINGEMENT" in the changelog would warrant a swift update.

I stress again that 2.2.0 and previous versions are formally retracted by FPC . The disputed code is available under the GPL (sf.net, freeclx package) though, so relicensing the RTL (and thus effectively every generated binary) under the GPL is possible in an emergency situation. However such a drastic copyright change should be prominently brought to the attention of users.

Yes, this needs to be fixed in intrepid. However, it also needs to be fixed in Dapper, Gutsy, and Hardy. It should be fixed by sync/merge for Jaunty. The fix for older releases requires a fair bit of investigation against rdepends to determine how many packages need adjustment, and what sort of adjustment, and I don't think it ought be considered before release. Please subscribe motu-sru as the investigation is completed for each of the affected releases.

Well I expected so much. Which is why I suggested the option of the prominent notice.

(and IMHO that still means that 2.2.2 should come ASAP, removing the entire 13 year old release history of our own FTP sites was not a step we took lightly, and it is then most annoying to see the package still in the encumbered version in new releases of major distro's)

The four packages mentioned in this bug-report having build dependencies
 are licensed as follows:
imapcopy is GPL-2+
hedgewars is GPL-2
libhdate is GPL-3+
gearhead is LGPL-2+

I further found
m-tx is GPL-2+ (build depends on fp-compiler)
python-soappy is BSD-like (build depends on fpc)
poker-network is GPL-2 (build depends on python-soappy)

gearhead is a role playing game that does not have any depends or
reverse depends except it's own binaries.

$ reverse-build-depends fp-compiler
fpc
gearhead
hedgewars
imapcopy
lazarus
libhdate
m-tx

$ reverse-build-depends gearhead
<empty line>

$ reverse-build-depends fpc
lazarus
python-soappy

$ reverse-build-depends python-soappy
poker-network

First, FPC is perfectly usable by itself and comes with an IDE.

Second Lazarus is an advanced IDE to generate programs. While Lazarus itself is GPL, the programs that it generates are not subject to the GPL, but to LGPL with modifications, as the normal FPC license. So there people could surely get hurt with this. Specially since a lot of users on Linux are ex-Kylixers with their commercial packages.

But the main point is that due to a copyright issue that was brought to our attention by Borland/Codegear, we rewrote significant parts of the RTL, and agreed with Borland to take the old , encumbered parts down. Codegear was all friendly but firm about it, and we wanted to respond similarly.

It is then frustrating to see releases done with the encumbered code almost two and an half months (August 11th) after this release, while we retracted all these versions on August 11th.

And yes, mea culpa. I should have started kicking people earlier, maybe mail legal at canonical since package maintainers might not always read release manifests, release comments on the site and in general not have an idea on what goes on.

On the other hand, the release manifest does mention a copyright dispute, and with whom, and is quoted in the post of 30-09. Moreover, the GPL escape is not mentioned till now by me (since not publically know). So to be honest I'm a bit surprised, how lax the distributions react to copyright disputes clearly annotated and known.

Even in Jaunty fpc is not synced to the current version in Debian. Does anybody know why not? I thought that Jaunty would be synced with Debian unstable, or is that not done with packages that have a Ubuntu packaged version? If the latter is the case, could we just request a sync from debian for the current version and fix the problem as in bug 260464 after that (with respect to the licensing issue that bug is minor)? Or should I test to build fpc in jaunty and file the debdiff for jaunty here?

Can anybody comment on the process that is made for this SRU bug (as discussed on IRC some weeks ago)? (It looks like nothing is happening here, but I might be missing something).

Hi,

fpc hasn't been synced yet as there are Ubuntu modifications to
the current package. The person that did those modifications stated
that it is safe to sync the package as Debian has a fixed version, so we
can go ahead and sync.

For an SRU it needs someone to investigate the status on each affected
release and document what is needed for each and come up with a plan.

Thanks,

James

ACK of the sync request.

Thanks,

James

Note that if there are local mods, don't forget to send them upstream to FPC. The freeze for 2.2.4 starts mid december

> For an SRU it needs someone to investigate the status on each affected
> release and document what is needed for each and come up with a plan.

Can I find documentation somewhere what kind of information is needed,
and how to obtain it? I found [1] but there is no mention of
dependencies of the SRU package there. I am willing to help, I guess I
could try and build fpc on all the previous Ubuntu releases, as well as
the rdependent packages? Is this best done after it is synced in Jaunty?

I have problems with building lazarus in a pdebuild environment, because
the clean rule that is run before the package is put in the jail
involves too much for my system. Is there a better approach than using
pdebuild?

Does anybody see any problem with the licenses mentioned in a previous
comment [2]?

Is there a good example of an SRU bug which involved as much as this
bug, so that I have an idea of how this should be handled?

[1] https://wiki.kubuntu.org/DistributedDevelopment/Requirements/SRU
[2] https://bugs.launchpad.net/ubuntu/+source/fpc/+bug/275688/comments/22

Kind regards,
Paul

Hi Paul,

The documentation on SRUs is at

  http://wiki.ubuntu.com/StableReleaseUpdates

which should get you started.

Thanks,

James

[Updating] fpc (2.2.0-dfsg1-9ubuntu1 [Ubuntu] < 2.2.2-4 [Debian])
 * Trying to add fpc...
  - <fpc_2.2.2.orig.tar.gz: downloading from http://ftp.debian.org/debian/>
  - <fpc_2.2.2-4.diff.gz: downloading from http://ftp.debian.org/debian/>
  - <fpc_2.2.2-4.dsc: downloading from http://ftp.debian.org/debian/>
I: fpc [universe] -> fpc_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fpc-source_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-compiler_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-ide_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-utils_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-docs_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-units-rtl_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-units-base_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-units-fcl_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-units-fv_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-units-gtk_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-units-gtk2_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-units-gnome1_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-units-db_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-units-gfx_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-units-net_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-units-misc_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-units-multimedia_2.2.0-dfsg1-9ubuntu1 [universe].
I: fpc [universe] -> fp-units-i386_2.2.0-dfsg1-9ubuntu1 [universe].

I am looking into how to get sbuild to work... (of course it doesn't want to do what I want straight away), but in the mean time I like to note for this bug that with only the sync with debian bug #260464 appears to be back, as can be seen in the build log of lazarus [1]. When I look at the upstream bugreport [2], it looks like this bug is fixed upstream from fpc 2.3.1

Once I get sbuild to run I will give an additional debdiff on this problem but the debdiff attached to this bug *should* work (apart from the changelog). I will report back.

Is there any way of marking in Launchpad that this bug is the reason why lazarus does not build in jaunty?

[1] http://launchpadlibrarian.net/19834865/buildlog_ubuntu-jaunty-i386.lazarus_0.9.26-2_FAILEDTOBUILD.txt.gz
[2] http://mantis.freepascal.org/view.php?id=11837

I have build fpc in jaunty with the attached changes. Lazarus build fine in jaunty after that. I can also upload the .diff.gz, but that is quiet crowded with touched Makefiles. Just tell me if they are needed.

(Afaik that bug is not fixed in 2.2.2, which is from Aug 11th, and this fix is from Aug 20th )

So far I have tested building 2.2.2-4ubuntu1 on gutsy, intrepid and hardy. Gutsy fails because of
  Processing fpcsrc/utils/Makefile.fpc
  Error: Target "linux", package "fcl-base" not found
Googling for that error it looks like that is due to a different location of the fpc source [0]
Hardy and Intrepid build fine. See [1], including the logs.
I did not even start building on Dapper because the build depends are not fulfilled (fp-compiler, fp-units-base and fp-utils)

I am wondering thou, is this the way to go? Really trying to extract the relevant parts from the 2.2.2 version to patch the earlier releases is a bridge to far for me (with my current programming skills).

Should the Dapper and Gutsy version just be changed to reflect the change in licensing? How would we achieve this anyway? I guess than gearhead and python-soappy also need relicensing (how does that work? I that feasible?)

Although I am still willing to help, I could do with some more directions. I am pretty new to packaging (~3 packages) and am not really into programming. Rebuilding all the build depends in the different releases, right?

And just to be sure that I understand the situation:
All programs build with the old version of fpc can *only* be licensed under GPL (which version by the way?)
All programs build with the 2.2.2 version of fpc can be licensed under GPL or LGPL.

[0] http://<email address hidden>/msg08706.html
[1] https://launchpad.net/~paul-climbing/+archive

Well, In my opinion anything base on the older versions is not supported by FPC, and we prefer you remove them from Ubuntu versions that are not worth fixing, rather than relicense them. We didn't remove all older releases from our own site lightly, and the risk on confusion is too big.

Also because it would not be fair to the other party in the copyright dispute to have these versions longer in circulation in any form, the reengineering of the disputed code took quite long, and the FPC release that fixes it is also already over 4 months old.

Moreover the relicensing option also was not properly verified or communicated with them, and just something proposed on the maillist, so you would do this on your own peril, and Ubuntu, and Ubuntu alone would be responsible for the consequences since FPC removed all disputed sources from its servers, and no longer distributes them.

In summary, I don't think relicensing is a serious option, it is simply too sensitive legally, and the GPL option never should have mentioned, since not verified by legal council or with the other party.

With respect to the building problems, could it be that the build system is poluted with an older install ? A FPC build should be always the same, so the logical conclusion is that there is something different on the buildmachines. (IOW a different version installed to bootstrap, one a full version, one only the cmdline compiler)

Subscribed gNS group, as it also affects us.

Sorry, "It" being "The copyright issue pre 2.2.2"

I changed the title and description of this bug to reflect where this bug really is about at the moment. Please correct if it does not match the facts, it is written as I understand the issue.

> With respect to the building problems, could it be that the build system is poluted with an older install ? A FPC build should be always the same, so the logical conclusion is that there is something different on the buildmachines. (IOW a different version installed to bootstrap, one a full version, one only the cmdline compiler)

I am pretty sure that it is. The build system contains the current version of fpc in *that* release. That means that the version of fpc that builds the new one gets older as we move to older Ubuntu releases. There is no bootstrapping involved in the building (AFAICT).

So if I understand your remark correctly, it is very well possible that these older versions are just unable to build the new version? Could you indicate how that might be solved?

FPC keeps a typical building chain where release N is only guaranteed to build with release N-1. One can be lucky from time to time with point releases (x.y.n also buildable with x.y.n-1)

Note that the only binary that is really necessary from the older release to bootstrap is the compiler binary itself (ppc386 or ppcx64 for x86_64).

I don't know what the debian/ubuntu policies are, but in FreeBSD afaik this was avoided by having a separate port for the bootstrap compiler, which can be quicker and easier bumped than the main release.

First results (intrepid) for rebuilding packages with reverse build depend on fpc:
gearhead builds normal in intrepid
hedgewars builds normal in intrepid
imapcopy builds normal in intrepid
libhdate builds normal in intrepid
m-tx builds normal in intrepid

lazarus fails to build in intrepid with:
gtkproc.pp(674,11) Error: Forward declaration not solved "MergeClipping(TDeviceContext, PGdkGC, LongInt, LongInt, LongInt, LongInt, PGdkBitMap, LongInt, LongInt,var PGdkBitMap)"

The following commands didn't show any change except the own I made in the changelog:
$ debdiff <original>.dsc <new-build>.dsc

and the following command showed:
$ debdiff <original>.deb <new-build>.deb

===========
$ debdiff gearhead_1.100-1_i386.deb ../../intepid/gearhead_1.100-1ubuntu0.1~ppa1i_i386.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)
------------------------------------------------
Installed-Size: [-972-] {+948+}
Maintainer: [-Ubuntu MOTU Developers <email address hidden>-]
[-Original-Maintainer:-] Kari Pahula <email address hidden>
Version: [-1.100-1-] {+1.100-1ubuntu0.1~ppa1i+}

===========
$ debdiff imapcopy_1.01+20060420-1_i386.deb ../../intepid/imapcopy_1.01+20060420-1ubuntu0.1~ppa1i_i386.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: libc6 (>= [-2.4-1)-] {+2.0)+}
Installed-Size: [-500-] {+556+}
Maintainer: [-Ubuntu MOTU Developers <email address hidden>-]
[-Original-Maintainer:-] RISKO Gergely <email address hidden>
Version: [-1.01+20060420-1-] {+1.01+20060420-1ubuntu0.1~ppa1i+}

===========
$ debdiff libhdate-dev_1.4.11-1_i386.deb ../../intepid/libhdate-dev_1.4.11-1ubuntu0.1~ppa1i_i386.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: libhdate1 (= [-1.4.11-1)-] {+1.4.11-1ubuntu0.1~ppa1i)+}
Maintainer: [-Ubuntu MOTU Developers <email address hidden>-]
[-Original-Maintainer:-] Debian Hebrew Packaging Team <email address hidden>
Version: [-1.4.11-1-] {+1.4.11-1ubuntu0.1~ppa1i+}

===========
$ debdiff libhdate-pascal_1.4.11-1_i386.deb ../../intepid/libhdate-pascal_1.4.11-1ubuntu0.1~ppa1i_i386.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-------------------------------------
-rw-r--r-- root/root /usr/lib/fpc/2.2.2/units/i386-linux/hdate/Package.fpc
-rw-r--r-- root/root /usr/lib/fpc/2.2.2/units/i386-linux/hdate/fpc_README
-rw-r--r-- root/root /usr/lib/fpc/2.2.2/units/i386-linux/hdate/hdate.o
-rw-r--r-- root/root /usr/lib/fpc/2.2.2/units/i386-linux/hdate/hdate.ppu
-rw-r--r-- root/root /usr/lib/fpc/2.2.2/units/i386-linux/hdate/hdate_dyn_pascal.o
-rw-r--r-- root/root /usr/lib/fpc/2.2.2/units/i386-linux/hdate/hdate_dyn_pascal.ppu

Fil...

hdate is a third party package (hebrew calendar from Ido Kanner iirc) and not part of the FPC distro. I suspect the hdate deb installs to the same dir as FPC?

The 18 month support period for Gutsy Gibbon 7.10 has reached its end of life -
http://www.ubuntu.com/news/ubuntu-7.10-eol . As a result, we are closing the
Gutsy task.

The world has turned a few more times, and in April FPC 2.2.4 came out.

Done: Debian Archive Maintenance <email address hidden>

Bug is archived. No further changes may be made.

@Artur Rona: I hope you only meant your comment for the Debian part of this bug. For Ubuntu's Intrepid,Hardy and Dapper the issue still stands.

@ Fail2Ban: please do not assign tags without first reading https://wiki.ubuntu.com/Bugs/Tags
Thanks in advance!

Thank you for reporting this bug to Ubuntu. Intrepid Ibex 8.10 reached EOL on 30 March 2010.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

Please feel free to report any other bugs you may find.
Thank you.

I realized I had made a mistake, Intrepid Ibex 8.10 "will reach" EOL on 30 "APRIL" 2010.

Sorry for this.

Anyway, I think that one month doesn't make any difference now.

Dapper Drake 6.06 reached End Of Life.

6.06 LTS doesn't reach end of life until June of 2011. While that doesn't imply we'll fix this bug for Dapper, it does mean that 'invalid' is the wrong category for this bug. It can be marked "Won't fix" if you believe the fix won't be done in the next year.

And in the mean time Dapper has reach EOL. I'd like to make it 'wont fix' but I dont' have the rights.

Hardy reached EOL in March. Turning this bug into Won't Fix.
https://lists.ubuntu.com/archives/ubuntu-announce/2013-March/000168.html