Hi Paul,
On Sat, 2025-01-18 at 19:57 +0100, Paul Gevers wrote:
> By the way, should lazarus do something similar? In my understanding all
> binaries build by fpc or lazarus get statically stuff linked in, so
> indeed everything in the FreePascal ecosystem should do this, right?
Yes indeed, but I
Hi Abou
On 18-01-2025 19:01, Abou Al Montacir wrote:
On 15-01-2025 22:48, Peter Blackman wrote:
so the package name only goes into the source, and then the package name
plus version gets into the binary?
Here is my understand on how this should work:
First we should patch fpc-depends to gener
Hi All,
On Wed, 2025-01-15 at 23:02 +0100, Paul Gevers wrote:
> Hi,
>
> On 15-01-2025 22:48, Peter Blackman wrote:
> > so the package name only goes into the source, and then the package name
> > plus version gets into the binary?
Here is my understand on how this should work:
First we should p
On 17/01/2025 09:42, Abou Al Montacir wrote:
Hi,
On Wed, 2025-01-15 at 21:57 +, Peter B wrote:
I'm thinking now, that src:lazarus and src:castle-model-viewer are the
only packages that would benefit in any way.
I think only libraries will be affected by a rebuild requirement.
This means la
Hi,
On Wed, 2025-01-15 at 21:48 +, Peter Blackman wrote:
> @Abou,
> I can't see any purpose in having this bug assigned to winff, as winff
> does not provide or consume any ppus from other packages.
> I'm thinking adding to the workflow notes for fpc
> https://salsa.debian.org/pascal-team/fpc
Hi,
On Wed, 2025-01-15 at 21:57 +, Peter B wrote:
> I'm thinking now, that src:lazarus and src:castle-model-viewer are the
> only packages that would benefit in any way.
I think only libraries will be affected by a rebuild requirement.
This means lazarus (lcl part), libqt*pas, and castle game
Hi,
On 15-01-2025 22:48, Peter Blackman wrote:
so the package name only goes into the source, and then the package name
plus version gets into the binary?
Yes.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
Hi,
On 15-01-2025 22:57, Peter B wrote:
2) this doesn't automatically show up on the Release Team radar, so
this still doesn't trigger rebuilds when needed (it does mean that the
package gets rebuild before a Debian release, but that's not enough).
Bit is it still worth doing? Its easy eno
Hi Paul,
On 05/01/2025 21:27, Paul Gevers wrote:
Hi,
On 05-01-2025 19:22, Abou Al Montacir wrote:
As per the agreement about using 'Static-Built-Using' field by
packages compiling with FPC, I reassign this ticket to winff so that
maintainer can add the field and close this ticket.
Two remar
Hi
On 06/01/2025 18:15, Paul Gevers wrote:
Hi,
On 06-01-2025 12:38, Peter B wrote:
ISTM that the "exactly equal" version equality of the dependency
cannot itself cause the package
to be rebuilt, as the package will now FTBFS because the exact
version of the dependency will no longer be availa
Hi,
On 06-01-2025 12:38, Peter B wrote:
ISTM that the "exactly equal" version equality of the dependency cannot
itself cause the package
to be rebuilt, as the package will now FTBFS because the exact version
of the dependency will no longer be available.
The version should be calculated durin
On 05/01/2025 18:22, Abou Al Montacir wrote:
On Wed, 2024-04-24 at 14:53 +0100, Peter B wrote:
Setting the 'Static-Built-Using' field in the control files of packages
built with fpc should fix this.
Oops, I meant to update my comment on that after further investigation!
I had assumed incorr
Hi,
On 05-01-2025 19:22, Abou Al Montacir wrote:
As per the agreement about using 'Static-Built-Using' field by packages
compiling with FPC, I reassign this ticket to winff so that maintainer
can add the field and close this ticket.
Two remarks:
1) don't other packages need this too? Stuff fr
Control: reassign -1 winff
Control: retitle -1 Winff should declare Static-Built-Using in debian/control
file
On Wed, 2024-04-24 at 14:53 +0100, Peter B wrote:
> Setting the 'Static-Built-Using' field in the control files of packages
> built with fpc should fix this.
As per the agreement about u
On 18/06/2023 09:45, Abou Al Montacir wrote:
However, fpc units are kind of statically linked libraries. And in
this case, one ma want a rebuild of all reverse dependencies in order
to ensure a bug fix is propagated on all binaries.
Example: Suppose we discover a vulnerability in a unit. We wa
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 v
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
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
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
19 matches
Mail list logo
