Bug#1026719: [Pkg-pascal-devel] Bug#1026719: Bug#1026719: vmg: FTBFS: /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory
control: reassign -1 fpc control: reopen 967348 On Fri, 2023-01-06 at 13:59 +0100, Abou Al Montacir wrote: > I do agree. > I'll revert it. > Done -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1026719: [Pkg-pascal-devel] Bug#1026719: Bug#1026719: vmg: FTBFS: /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory
control: reassign -1 control: reopen 967348 On Fri, 2023-01-06 at 13:59 +0100, Abou Al Montacir wrote: > I do agree. > I'll revert it. Done -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1026719: [Pkg-pascal-devel] Bug#1026719: vmg: FTBFS: /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory
Hi Paul, On Mon, 2023-01-02 at 07:29 +0100, Paul Gevers wrote: > After this discussion (thanks for having it), I think it's best to > reopen bug 967348, have fp-units-gtk2-x.y.z depend on libgtk2.0-dev > again and *stop shipping* fp-units-gtk2-x.y.z once libgtk2.0-dev needs > to be removed. I do agree. I'll revert it. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1026719: vmg: FTBFS: /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory
Hi Abou, On 01-01-2023 23:51, Abou Al Montacir wrote: Yes, sure. But for bookworm we'll apparently stay with gtk2, so let's make that that works, at least. Maybe this makes sens, but I can't revert a decision made by the team on my own, because a user decided something else. I'll wait for feedback from others. After this discussion (thanks for having it), I think it's best to reopen bug 967348, have fp-units-gtk2-x.y.z depend on libgtk2.0-dev again and *stop shipping* fp-units-gtk2-x.y.z once libgtk2.0-dev needs to be removed. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1026719: [Pkg-pascal-devel] Bug#1026719: vmg: FTBFS: /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory
Abou Al Montacir, le dim. 01 janv. 2023 23:51:45 +0100, a ecrit: > > Things were just working perfectly previously. Why breaking the build > > of packages using fp-units-gtk2-3.2.0 by dropping the pull? Is there an > > *actual* reason for not making fp-units-gtk2-3.2.0 pull it, > > Yes, the reason is to close the bug [1]https://bugs.debian.org/cgi-bin/ > bugreport.cgi?bug=967348 Oh, so it actually is possible to build fp-units-gtk2-3.0.0 without build-depending on libgtk2.0-dev? That was surprising but then yet I understand that position and that it allows you to "close" 967348. But all users of fp-units-gtk2 will still have to wait for a fp-units-gtk3 to become available anyway. Samuel
Bug#1026719: [Pkg-pascal-devel] Bug#1026719: vmg: FTBFS: /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory
On Sun, 2023-01-01 at 21:45 +0100, Samuel Thibault wrote: > > • Technically, Lazarus doe snot need libgtk2.0-dev for running, and thus > > should not pull it. > > Lazarus itself, no indeed. But the fp-units-gtk2-3.2.0 package does not > make any sense without libgtk2.0-dev, since there is no way to use the > former without the latter. That was the reason why fp-units-gtk2-x.y.z made dependent on the libgtk2.0-dev. However, with deprecation of gtk2, we decided to relax that constraint. Of course, one can argue, as you do, that the bindings packages does not make sens without depending on the libraries package. That makes sense, but we discussed this and relaxing the dependency was the easiest way for us, given that FPC does not seem to be ready to provide bindings for gtk3. > > • Technically, FPC does not need any GTK related lib, it only provide > > binding > > units. > > Yes, and *all* languages that provide bindings do provide the required > pulls so that users of the bindings don't have to care about what > should be pulled. The information is recorded in only the bindings > package, and not sprinkled over all packages that happen to use it > (which would require changes in all of them for no good reason whenever > the underlying C library happens to change its C API, for instance). I tend to agree here. > > Things were just working perfectly previously. Why breaking the build > of packages using fp-units-gtk2-3.2.0 by dropping the pull? Is there an > *actual* reason for not making fp-units-gtk2-3.2.0 pull it, Yes, the reason is to close the bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967348 > how does it > hurt in any way? Is that because fpc-3.2.0 happens to depend on it? > Then why does it do so, since from what you say it does not actually > need it? fpc-x.y.z is a meta-package that is there to pull all packages created by the fpc source package. > > Really, I don't understand: fp-units-gtk2-3.2.0 does need libgtk2.0-dev > to work at all, while you are saying that fpc-3.2.0 does not need > fp-units-gtk2-3.2.0 to work. The current "Depends" that are set on those > package are exactly the inverse of that... You are confused between fpc as a meta-package and fpc as an executable. The package depends on all fp-units-* created by fpc source package. While the executable (compiler) does not. > > > • For building, Lazarus build depends on libgtk2.0-dev, until it will > > migrate > > to gtk3. And so shall do all programs that use it. > > Yes, sure. But for bookworm we'll apparently stay with gtk2, so let's > make that that works, at least. Maybe this makes sens, but I can't revert a decision made by the team on my own, because a user decided something else. I'll wait for feedback from others. > > > I hope this makes it clear, why neither Lazarus, nor FPC or any of their > > packages should pull libgtk2.0-dev package. > > No, not at all. > > > You should handle this bug in VMG, and probably the best way to do it is to > > build depend on libgtk-2.0-dev > > From point point of view it's not the best way since it means that'll be > yet something more to change when switching to gtk3, then to gtk4, etc. > while everything could be just handled in the bindings package. Yes, ideally it should be that way. In practice, I'm not sure it will be possible. > > > until you fix [2]https://bugs.debian.org/cgi-bin /bugreport.cgi?bug=967799 > > That only boils down to making lazarus support gtk3, since vmg just > uses LCL. If Lazarus was providing a gtk bindings package which does > not encode the 2 vs 3 notion, the vmg package would be more than > happy to just use it and not have to care at all about the underlying > incompatibilities. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1026719: vmg: FTBFS: /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory
Abou Al Montacir, le dim. 01 janv. 2023 20:02:51 +0100, a ecrit: > Lucas Nussbaum, le mar. 20 déc. 2022 18:31:46 +0100, a ecrit: > > Linking ./vmg > /usr/bin/ld.bfd: cannot find -lgdk-x11-2.0: No such file or > directory > /usr/bin/ld.bfd: cannot find -lgtk-x11-2.0: No such file or > directory > > ... > > /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory > > > Yes, we had discussed it a bit in #967798, it is an issue in Lazarus: > fp-units-gtk2-3.2.0 used to have the libgtk2.0-dev dependency, but > fp-units-gtk2-3.2.2 doesn't any more, but it should, it shouldn't be up > to users of the gtk2 unit to know which C dependency it should take. > > > Sorry, but, as FPC maintaining team member, I don't share this __ should __ > statement for the following reasons. > > • GTK2 is declared as deprecated in Debian since long time ago. Yes, sure. > • Technically, Lazarus doe snot need libgtk2.0-dev for running, and thus > should not pull it. Lazarus itself, no indeed. But the fp-units-gtk2-3.2.0 package does not make any sense without libgtk2.0-dev, since there is no way to use the former without the latter. > • Technically, FPC does not need any GTK related lib, it only provide > binding > units. Yes, and *all* languages that provide bindings do provide the required pulls so that users of the bindings don't have to care about what should be pulled. The information is recorded in only the bindings package, and not sprinkled over all packages that happen to use it (which would require changes in all of them for no good reason whenever the underlying C library happens to change its C API, for instance). Things were just working perfectly previously. Why breaking the build of packages using fp-units-gtk2-3.2.0 by dropping the pull? Is there an *actual* reason for not making fp-units-gtk2-3.2.0 pull it, how does it hurt in any way? Is that because fpc-3.2.0 happens to depend on it? Then why does it do so, since from what you say it does not actually need it? Really, I don't understand: fp-units-gtk2-3.2.0 does need libgtk2.0-dev to work at all, while you are saying that fpc-3.2.0 does not need fp-units-gtk2-3.2.0 to work. The current "Depends" that are set on those package are exactly the inverse of that... > • For building, Lazarus build depends on libgtk2.0-dev, until it will > migrate > to gtk3. And so shall do all programs that use it. Yes, sure. But for bookworm we'll apparently stay with gtk2, so let's make that that works, at least. > I hope this makes it clear, why neither Lazarus, nor FPC or any of their > packages should pull libgtk2.0-dev package. No, not at all. > You should handle this bug in VMG, and probably the best way to do it is to > build depend on libgtk-2.0-dev >From point point of view it's not the best way since it means that'll be yet something more to change when switching to gtk3, then to gtk4, etc. while everything could be just handled in the bindings package. > until you fix [2]https://bugs.debian.org/cgi-bin /bugreport.cgi?bug=967799 That only boils down to making lazarus support gtk3, since vmg just uses LCL. If Lazarus was providing a gtk bindings package which does not encode the 2 vs 3 notion, the vmg package would be more than happy to just use it and not have to care at all about the underlying incompatibilities. Samuel
Bug#1026719: vmg: FTBFS: /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory
Hi Samuel, > On Tue, 20 Dec 2022 19:27:23 +0100 Samuel Thibault > wrote: > Control: reassign -1 lazarus > Control: affects -1 + vmg > > Hello, > > Lucas Nussbaum, le mar. 20 déc. 2022 18:31:46 +0100, a ecrit: > > > Linking ./vmg > > > /usr/bin/ld.bfd: cannot find -lgdk-x11-2.0: No such file or directory > > > /usr/bin/ld.bfd: cannot find -lgtk-x11-2.0: No such file or directory ... > > > /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory > > Yes, we had discussed it a bit in #967798, it is an issue in Lazarus: > fp-units-gtk2-3.2.0 used to have the libgtk2.0-dev dependency, but > fp-units-gtk2-3.2.2 doesn't any more, but it should, it shouldn't be up > to users of the gtk2 unit to know which C dependency it should take. Sorry, but, as FPC maintaining team member, I don't share this __ should __ statement for the following reasons. * GTK2 is declared as deprecated in Debian since long time ago. * Technically, Lazarus doe snot need libgtk2.0-dev for running, and thus should not pull it. * Technically, FPC does not need any GTK related lib, it only provide binding units. So it should not pull it either. * For building, Lazarus build depends on libgtk2.0-dev, until it will migrate to gtk3. And so shall do all programs that use it. I hope this makes it clear, why neither Lazarus, nor FPC or any of their packages should pull libgtk2.0-dev package. You should handle this bug in VMG, and probably the best way to do it is to build depend on libgtk-2.0-dev until you fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967798 -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1026719: vmg: FTBFS: /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory
Control: reassign -1 lazarus Control: affects -1 + vmg Hello, Lucas Nussbaum, le mar. 20 déc. 2022 18:31:46 +0100, a ecrit: > > Linking ./vmg > > /usr/bin/ld.bfd: cannot find -lgdk-x11-2.0: No such file or directory > > /usr/bin/ld.bfd: cannot find -lgtk-x11-2.0: No such file or directory > > /usr/bin/ld.bfd: cannot find -lX11: No such file or directory > > /usr/bin/ld.bfd: cannot find -lgdk_pixbuf-2.0: No such file or directory > > /usr/bin/ld.bfd: cannot find -lgobject-2.0: No such file or directory > > /usr/bin/ld.bfd: cannot find -lglib-2.0: No such file or directory > > /usr/bin/ld.bfd: cannot find -lgthread-2.0: No such file or directory > > /usr/bin/ld.bfd: cannot find -lgmodule-2.0: No such file or directory > > /usr/bin/ld.bfd: cannot find -lpango-1.0: No such file or directory > > /usr/bin/ld.bfd: cannot find -lcairo: No such file or directory > > /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory Yes, we had discussed it a bit in #967798, it is an issue in Lazarus: fp-units-gtk2-3.2.0 used to have the libgtk2.0-dev dependency, but fp-units-gtk2-3.2.2 doesn't any more, but it should, it shouldn't be up to users of the gtk2 unit to know which C dependency it should take. Samuel
Bug#1026719: vmg: FTBFS: /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory
Source: vmg Version: 3.7.1-7 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs User: lu...@debian.org Usertags: ftbfs-20221220 ftbfs-bookworm Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > /usr/bin/i686-w64-mingw32-windres fpcmagnifier.rc fpcmagnifier.res > /usr/bin/i686-w64-mingw32-windres magnifier.rc magnifier.res > lazres startform.lrs startform.lfm > startform.lfm ResourceName='TvStartWindow' Type='FORMDATA' > fpc -S2cgi -O1 -gl -vewnhi -l \ > -Fu/usr/lib/lazarus/default/lcl/units/x86_64-linux/ \ > -Fu/usr/lib/lazarus/default/lcl/units/x86_64-linux/gtk2/ \ > -Fu/usr/lib/lazarus/default/packager/units/x86_64-linux/ \ > -Fu/usr/lib/lazarus/default/components/lazutils/lib/x86_64-linux/ \ > -Fu. -o./vmg -dLCL -dLCLgtk2 magnifier.dpr > Hint: Start of reading config file /etc/fpc.cfg > Hint: End of reading config file /etc/fpc.cfg > Free Pascal Compiler version 3.2.2+dfsg-17 [2022/11/27] for x86_64 > Copyright (c) 1993-2021 by Florian Klaempfl and others > Target OS: Linux for x86-64 > Compiling magnifier.dpr > Compiling glass.pas > Compiling constants.pas > Compiling appsettings.pas > Compiling translationsvmg.pas > appsettings.pas(70,28) Hint: Parameter "Sender" not used > appsettings.pas(71,20) Hint: Parameter "Sender" not used > appsettings.pas(248,3) Note: Local variable "APath" not used > appsettings.pas(249,3) Note: Local variable "LocalConfigFile" not used > appsettings.pas(250,3) Note: Local variable "attrs" not used > glass.pas(205,3) Note: Local variable "buffer" not used > glass.pas(206,3) Note: Local variable "memstream" not used > glass.pas(483,3) Note: Local variable "c" not used > glass.pas(484,3) Note: Local variable "srcRect" not used > glass.pas(484,12) Note: Local variable "destRect" not used > glass.pas(486,3) Note: Local variable "lCurWindow" not used > glass.pas(486,15) Note: Local variable "lVMGWindow" not used > glass.pas(487,3) Note: Local variable "lCurWindowText" not used > glass.pas(488,3) Note: Local variable "i" not used > glass.pas(490,3) Note: Local variable "bmpRetinaDisplay" not used > glass.pas(93,33) Hint: Parameter "DestCanvas" not used > glass.pas(658,3) Note: Local variable "dwROP" is assigned but never used > glass.pas(770,3) Note: Local variable "i" not used > glass.pas(770,6) Note: Local variable "MinWidth" not used > glass.pas(770,16) Note: Local variable "MinHeight" not used > glass.pas(775,9) Note: Local variable "stepMinor" is assigned but never used > glass.pas(775,20) Note: Local variable "tickSize" is assigned but never used > glass.pas(775,30) Note: Local variable "tickCount" not used > glass.pas(916,3) Note: Local variable "I" not used > glass.pas(986,47) Hint: Local variable "DrawInfo" does not seem to be > initialized > glass.pas(112,31) Hint: Parameter "DC" not used > Compiling app.pas > Compiling plugins.pas > Compiling plugininfo.pas > app.pas(113,15) Warning: An inherited method is hidden by "ShowHelp(TObject);" > Compiling about.pas > about.pas(63,24) Hint: Parameter "Sender" not used > Compiling configdlg.pas > configdlg.pas(62,24) Hint: Parameter "Sender" not used > configdlg.pas(63,25) Hint: Parameter "Sender" not used > configdlg.pas(63,46) Hint: Parameter "Action" not used > configdlg.pas(35,54) Hint: Unit "constants" not used in configdlg > configdlg.pas(77,3) Hint: Unit "glass" not used in configdlg > app.pas(106,26) Hint: Parameter "Sender" not used > app.pas(94,27) Hint: Parameter "Sender" not used > app.pas(184,3) Note: Local variable "lResult" not used > app.pas(521,3) Note: Local variable "OSVersion" not used > app.pas(123,38) Hint: Parameter "Sender" not used > app.pas(124,32) Hint: Parameter "AID" not used > app.pas(108,25) Hint: Parameter "Sender" not used > app.pas(108,42) Hint: Parameter "Shift" not used > app.pas(108,62) Hint: Parameter "X" not used > app.pas(108,65) Hint: Parameter "Y" not used > app.pas(109,30) Hint: Parameter "uID" not used > app.pas(114,28) Hint: Parameter "Sender" not used > app.pas(115,36) Hint: Parameter "Sender" not used > app.pas(107,24) Hint: Parameter "Sender" not used > app.pas(951,44) Hint: Local variable "DrawInfo" does not seem to be > initialized > app.pas(96,31) Hint: Parameter "Sender" not used > app.pas(84,34) Hint: Parameter "Sender" not used > app.pas(85,37) Hint: Parameter "Sender" not used > app.pas(110,28) Hint: Parameter "Sender" not used > app.pas(111,28) Hint: Parameter "Sender" not used > app.pas(112,32) Hint: Parameter "Sender" not used > app.pas(90,29) Hint: Parameter "Sender" not used > app.pas(121,28) Hint: Parameter "Sender" not used > app.pas(91,34) Hint: Parameter "Sender" not used > app.pas(89,27) Hint: Parameter "Sender" not used > app.pas(97,29) Hint: Parameter "Sender" not used > app.pas(98,30) Hint: Parameter "Sender" not used > app.pas(99,29) Hint: Parameter "Sender" not used > app.pas(99,50) Hint: Parameter "CloseAction" not used >
