Bug#997948: winff FTBFS: Fatal: (10022) Can't find unit Interfaces used by winff

[Adrian Bunk]

Source: winff
Version: 1.5.5-8
Severity: serious
Tags: ftbfs bookworm sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/winff.html

...
(10028) Recompiling Interfaces, checksum changed for /usr/lib/x86_64-linux-gnu/fpc/3.2.2/units/x86_64-linux/rtl/system.ppu
/build/1st/winff-1.5.5/winff.lpr(26,3) Fatal: (10022) Can't find unit Interfaces used by winff
Fatal: (1018) Compilation aborted
Error: /usr/bin/ppcx64 returned an error exitcode
Error: (lazarus) Compile Project, Target: winff: stopped with exit code 1
Error: (lazbuild) failed compiling of project /build/1st/winff-1.5.5/winff.lpi
make[1]: *** [debian/rules:16: override_dh_auto_build-arch] Error 2

[Paul Gevers]

Control: reassign -1 lazarus
Control: affects -1 winff
Control: severity -1 important
Control: retitle -1 src:lazarus should embed fpc version it works with

Hi,

A retry worked. It seems to me that the failure was due to lazarus not
having been rebuild against the latest fpc in the archive. But in Debian
I'd expect package relations to embed the knowledge to prevent this from
happening.

Similar to the discussion in bug 997940 about src:castle-game-engine.

Paul

[Abou Al Montacir]

Hi Paul

A retry worked. It seems to me that the failure was due to lazarus not

having been rebuild against the latest fpc in the archive.

More exactly, because the installed lcl-units-* were not build using the installed FPC.

But in Debian

I'd expect package relations to embed the knowledge to prevent this from

happening.

This is generally the case except when FPC get upgraded to a new version, which is generally a transitory situation for a very short time.

Similar to the discussion in bug 997940 about src:castle-game-engine.

It is not  exactly the same. Lazarus is an IDE + framework (LCL).

The IDE itself can work with whatever FPC version and with many LCL versions. So in principle, one can install the IDE and have a custom FPC + LCL.

One problem here is that the LCL is packaged with the IDE, and this is a issue from upstream not separating the IDE development from the framework development.

I don't like the idea to enforce the dependency because in principle, the same instance of Lazarus IDE can work with FPC-2.2.0 and FPC-2.2.2 which allows a developer to have time to migrate his application broken by a FPC or LCL upgrade wile using the last IDE. I personally use this feature for a SW that is tightly linked to LCL and thus using a new Lazarus with an old LCL until upgrade is done.
--

Cheers,
Abou Al Montacir

[Paul Gevers]

Hi Abou,

On 28-11-2021 20:51, Abou Al Montacir wrote:
>> But in Debian
>> I'd expect package relations to embed the knowledge to prevent this from
>> happening.
> This is generally the case except when FPC get upgraded to a new
> version, which is generally a transitory situation for a very short time.

I forgot how we do that then, but how do we guarantee that the period is
short? Does it show up on the Release Team transition trackers [1]
somehow? Or do we have to always remember to ask for a rebuild of
lazarus ourselves (if we don't have a reason to upload a new version of
lazarus)?

Paul

[1] https://release.debian.org/transitions/

[Abou Al Montacir]

Hi Paul,

On Sun, 2021-11-28 at 22:11 +0100, Paul Gevers wrote:

I forgot how we do that then, but how do we guarantee that the period is
short? Does it show up on the Release Team transition trackers [1]
somehow? Or do we have to always remember to ask for a rebuild of
lazarus ourselves (if we don't have a reason to upload a new version of
lazarus)?

I'm not very familiar with transitions, but we used to ask for a rebuild of Lazarus and other libs (CGE, ...) if this happens.

Of course if we can make this automatic, then this is even better. 

Do you have any idea in mind?

[Abou Al Montacir]

Control: retitle -1 FPC should provide a  way to trigger automatic rebuild of Pascal libraries supplying units.

Control: reassign -1 fpc

Hi All,

I'm not very familiar with transitions, but we used to ask for a rebuild of Lazarus and other libs (CGE, ...) if this happens.

Of course if we can make this automatic, then this is even better. 

Do you have any idea in mind?

After thinking more about this issue, I don't consider this a valid bug against Lazarus.

The real issue is that FPC does not have a mean, today, to automatically trigger a rebuild of all source packages that supply units.

This is the same for CGE, and other Pascal libraries.

So I'm closing this ticket and will open a ticket for FPC to force rebuilding Pascal libraries.

[Abou Al Montacir]

Control: reassign -1 fp-units-rtl

[Abou Al Montacir]

The build of winff depends on lc-utils which depend on fpc-abi-3.2 that is a virtual package provided by fp-units-rtl-3.2 (3.2.0)

As I can not access the build log anymore, I can only make suppositions. And I suppose that what happened at that time was that fp-units-rtl-3.2 was pulled as 3.2.2 due to the the compiler itself was pulled as fp-compiler-3.2 (3.2.2) and the compiler have a strict dependency (= 3.2.2) on the rtl packages.

So, even if what happened was not the above supposition, we see that the fpc-abi is not carrying enough information on the version. I would recommend that it gets an additional digit or two to solve this issue and other similar issues.

I would recommend then to make the fpc-abi be fpc-abi-3.2.2 for now, and if happen to patch RTL units so that we change interface, then we use fpc-abi-3.2.2-n with n: Integer > 0.

What do you think?

[Abou Al Montacir]

Let's assume any FP unit is shipped in a package named fp-units-some-package-name.

Let's assume package fp-units-foo was changed and uploaded to unstable.

Let's assume package fp-units-bar depends directly or indirectly on fp-units-foo, then fp-units-bar needs to be rebuilt after every upload of fp-units-foo that changes interfaces checksum stored in the ppu files.

By depends directly we mean: fp-units-bar has fp-units-foo in its Build-Depends stanza.

By depends indirectly we mean: fp-units-bar has a package that depends directly or indirectly on fp-units-bar.

Please note that if fp-units-bar build depends on fp-units-foo, then it is likely that it will depend on it, unless fp-units-bar is build together with other set of fp-units-* packages that depend on fp-units-foo (like the case of Lazarus and FPC fp-units-* packages).

So now we need to implement this logic in a script that can be used by the release team or whatever bot that can trigger automatic rebuilds of fp-units-* packages.

For sake of simplicity, we ca assume that any new upload of fp-units-foo will break the interface which will cause higher load on building, but simpler logic to be implemented.

[Paul Gevers]

Hi Abou,

On 30-12-2021 16:26, Abou Al Montacir wrote:
> So now we need to implement this logic in a script that can be used by
> the release team or whatever bot that can trigger automatic rebuilds of
> fp-units-* packages.

The Release Team has tools in place to notify them if rebuilds are
needed by looking at upper limits of Depends that are no longer
satisfied. They show up as "auto-upperlimit-<pkg>" on the transitions
page [1]. If that <pkg> has "abi" in the name, it will be clear that a
rebuild is needed.

All the rebuilds are manually scheduled, but that's OK. As long as the
Release Team is aware via such a mechanism, it will be taken care of.

The other auto-<pkg> items show up if a binary package disappears from
the library section of the archive and another one shows up. This is how
c transitions happen, because it's near required that a library binary
package matches its SONAME, so when that's bumped (indicating a
transition) the package name has to be updated too. Maybe we should move
the fp-units-$bar packages to the library section too and embed the ABI
version into the package name.

Paul

[1] https://release.debian.org/transitions/

[Abou Al Montacir]

Hi Paul,

On Thu, 2021-12-30 at 19:24 +0100, Paul Gevers wrote:

Maybe we should move
the fp-units-$bar packages to the library section too and embed the ABI
version into the package name.

I like that idea. Let's go that way.

For FPC, libraries are already carrying the  ABI in their names. We only need to change them from section devel to section lib, but maybe we can convince release team to change a bit their script and check also for fp-units-* pattern in section devel. I don't think fp-unit-* make sense in the lib section.

For Lazarus, it used to be that way too, but was simplified to carry the upstream main version. We may revert to old way or implement a new and better way to do that.

[Abou Al Montacir]

Hi Paul,

I went again though this ticket and changed a bit my mind

On Thu, 2021-12-30 at 22:30 +0100, Abou Al Montacir wrote:

Maybe we should move 
the fp-units-$bar packages to the library section too and embed the ABI 
version into the package name.

I like that idea. Let's go that way.

...

I don't think fp-unit-* make sense in the lib section.

I think that the best place for fp-units-* is libdevel as they are very similar to the foo-dev packages.

what do you think? Will this solve the issue with regards to the release team script, or it handle only lib section in that particular way?

[Paul Gevers]

Hi Abou,

On 18-02-2023 12:17, Abou Al Montacir wrote:
> On Thu, 2021-12-30 at 22:30 +0100, Abou Al Montacir wrote:
>>> Maybe we should move
>>> the fp-units-$bar packages to the library section too and embed the ABI
>>> version into the package name.
>>
>> I like that idea. Let's go that way.
> ...
>> I don't think fp-unit-* make sense in the lib section.

> I think that the best place for /fp-units-*/ is /libdevel/ as they are
> very similar to the /foo-dev/ packages.

Ack.

> what do you think? Will this solve the issue with regards to the release

> team script, or it handle only /lib/ section in that particular way?

The Release Team scripts don't care about the section, they look at
installability. But if we compare the units to C libraries, we normally
asks library maintainers to *not* version the dev packages, because then
all reverse build dependencies need an update when the SONAME gets
bumped, making the transition process very labor-some.

What we want to achieve here is a way to ensure packages are rebuild
(semi) automatically when the units require it. But we *also* want to
come up with a way that doesn't require changes in the reverse
dependencies at the same time. Consider also that adding new binary
packages require a trip through NEW. Would it make sense that every unit
provides a virtual abi package, which get embedded in the dependencies
during build time, such that when a unit bumps the virtual abi, the
release team tools notice and rebuilds can be triggered? Or is that what
we already more or less do?

Paul

[Abou Al Montacir]

Hi Paul,

On Mon, 2023-02-20 at 20:57 +0100, Paul Gevers wrote:

The Release Team scripts don't care about the section, they look at
installability. But if we compare the units to C libraries, we normally
asks library maintainers to *not* version the dev packages, because then
all reverse build dependencies need an update when the SONAME gets
bumped, making the transition process very labor-some.

What we want to achieve here is a way to ensure packages are rebuild
(semi) automatically when the units require it. But we *also* want to
come up with a way that doesn't require changes in the reverse
dependencies at the same time. Consider also that adding new binary
packages require a trip through NEW. Would it make sense that every unit
provides a virtual abi package, which get embedded in the dependencies
during build time, such that when a unit bumps the virtual abi, the
release team tools notice and rebuilds can be triggered? Or is that what
we already more or less do?

We already have fpc-abi-x.y.z that handle this.

However the problem of fpc-abi-* is that it does not carry a patch indicator.

So one way to fix this is that if we change any interface, we should bump its version.

Today we define it as fpc-abi-3.2.2. We can add a number like fpc-abi-3.2.2+p1, +p2, ...

This way each time we change an interface of any unit we bump the patch number.

However, this will solve only the problem for FPC, but not for LCL or any other units supplied by other projects (like CGE).

So maybe the solution would be to make the units dependency strict. I meant id fp-units-foo build depends on fp-unit-bar then it should depend on it strictly. And any rebuild of fp-units-bar shall trigger rebuild of fp-units-foo.

[Paul Gevers]

Hi,

On 17-06-2023 19:47, Abou Al Montacir wrote:
> So maybe the solution would be to make the units dependency strict. I
> meant id fp-units-foo build depends on fp-unit-bar then it should depend
> on it strictly. And any rebuild of fp-units-bar shall trigger rebuild of
> fp-units-foo.

This sounds very aggressive as I think most of the time it's unneeded.
As a release manager I prefer an *almost* good situation over a much
overly strict situation. Maybe autopkgtests can help? If we block
migration in situation where the rebuild should have happened, we're good.

Paul