Bug#1061009: winff: FTBFS: make[1]: *** [debian/rules:16: override_dh_auto_build-arch] Error 2
Control: found -1 3.0+dfsg1-5 Control: notfound -1 3.0+dfsg1-4 -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1060932: doublecmd: FTBFS: make[1]: *** [debian/rules:16: override_dh_install] Error 2
Control: found -1 3.0+dfsg1-5 Control: notfound -1 3.0+dfsg1-4 -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1060995: FTBFS: make[1]: *** [debian/rules:10: override_dh_auto_build] Error 2)
Control: found -1 3.0+dfsg1-5 Control: notfound -1 3.0+dfsg1-4 -- Cheers, Abou Al Montacir
Bug#1060932: (doublecmd: FTBFS: make[1]: *** [debian/rules:16: override_dh_install] Error 2)
Control: tag -1 - trixie -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1063475: RM: lazarus -- NVIU; Newer version is available
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: laza...@packages.debian.org Control: affects -1 + src:lazarus $ rmadison lazarus -s unstable lazarus| 2.2.6+dfsg2-2 | unstable | source, all lazarus| 3.0+dfsg1-7 | unstable | source, all
Bug#1063440: ITP: onedriver -- native Linux filesystem for Microsoft OneDrive
> This is a native Linux filesystem for Microsoft Onedrive Onedriver is a > native > Linux filesystem for Microsoft Onedrive. Files and metadata are > downloaded > on-demand instead of requiring you to sync your entire account to disk. What a nice feature, cont on me if you need help -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1061418: [Pkg-pascal-devel] Bug#1061418: Bug#1061418: castle-game-engine: please add support for loong64
As FPC maintainer, I would be glad to integrate any patch adding support of any arch into FPC 3.2.2. However I'll not do the port myself. -- Cheers, Abou Al Montacir On Wed, 2024-01-24 at 15:00 +0100, Michalis Kamburelis wrote: > For a new architecture, we need to have FPC (our compiler) with the > appropriate support for the architecture first. signature.asc Description: This is a digitally signed message part
Bug#1060273: [Pkg-pascal-devel] Bug#1060273: Bug#1060273: lazarus-3.0: Lazarus fails to compile itself
I've check more deeply this issue and could find that the IDE build make file
mixes old and newly compiled units which leads to a compiler deadlock in finding
the right ppu for dialogs unit.
I was able to patch ide/Makefile to resolve this locally, but I'm not this is
the right way to do, so I need more time to investigate this issue and confirm
with upstream that this is the right fix.
diff --git a/ide/Makefile.fpc b/ide/Makefile.fpc
index 9275b2b2..af53d875 100644
--- a/ide/Makefile.fpc
+++ b/ide/Makefile.fpc
@@ -179,21 +179,21 @@ idepackages:
#-
# compile IDE without extra packages
ide: $(COMPILER_UNITTARGETDIR) revisioninc
-$(MAKE) --assume-new=lazarus.pp lazarus$(EXEEXT)
OPT='$(DEFAULT_IDE_OPTIONS) $(LAZARUS_OPT) $(OPT)'
+$(MAKE) --assume-new=lazarus.pp lazarus$(EXEEXT) OPT='$(if $(patsubst
@%,@,${OPT}),${OPT},$(DEFAULT_IDE_OPTIONS) $(LAZARUS_OPT) $(OPT))'
#-
# compile IDE with some extra packages
bigide: $(COMPILER_UNITTARGETDIR) revisioninc
-$(DEL) $(COMPILER_UNITTARGETDIR)/pkgmanager$(PPUEXT)
-$(MAKE) --assume-new=lazarus.pp lazarus$(EXEEXT) OPT='$(OPT)
$(BIG_IDE_OPTIONS)'
+$(MAKE) --assume-new=lazarus.pp lazarus$(EXEEXT) OPT='$(if $(patsubst
@%,@,${OPT}),${OPT},$(OPT) $(BIG_IDE_OPTIONS))'
#-
starter: $(COMPILER_UNITTARGETDIR)
-$(MAKE) --assume-new=startlazarus.lpr startlazarus$(EXEEXT)
OPT='$(DEFAULT_IDE_OPTIONS) $(LAZARUS_OPT) $(OPT)'
+$(MAKE) --assume-new=startlazarus.lpr startlazarus$(EXEEXT) OPT='$(if
$(patsubst @%,@,${OPT}),${OPT},$(DEFAULT_IDE_OPTIONS) $(LAZARUS_OPT) $(OPT))'
#-
lazbuilder: $(COMPILER_UNITTARGETDIR)
-$(MAKE) --assume-new=lazbuild.lpr lazbuild$(EXEEXT)
OPT='$(DEFAULT_IDE_OPTIONS) $(OPT)'
+$(MAKE) --assume-new=lazbuild.lpr lazbuild$(EXEEXT) OPT='$(if
$(patsubst @%,@,${OPT}),${OPT},$(DEFAULT_IDE_OPTIONS) $(OPT))'
#-
all: ide starter lazbuilder
--
Cheers,
Abou Al Montacir
--
Cheers,
Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
Bug#1060932: marked as done (doublecmd: FTBFS: make[1]: *** [debian/rules:16: override_dh_install] Error 2)
Control: reassign -1 lazarus Control: fixed -1 3.0+dfsg1-6 This issue was caused by a Lazrus bug and is now fixed. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1060995: marked as done (ddrescueview: FTBFS: make[1]: *** [debian/rules:10: override_dh_auto_build] Error 2)
Control: reassign -1 lazarus Control: fixed -1 3.0+dfsg1-6 This issue was caused by a Lazrus bug and is now fixed. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1061009: marked as done (winff: FTBFS: make[1]: *** [debian/rules:16: override_dh_auto_build-arch] Error 2)
Control: reassign -1 lazarus Control: fixed -1 3.0+dfsg1-6 This issue was caused by a Lazrus bug and is now fixed. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1060189: [Pkg-pascal-devel] Bug#1060189: Bug#1060189: lazarus-src-3.0: diversion handling seems wrong (it works, but after an error)
Hi Paul, On Fri, 2024-01-12 at 20:12 +0100, Paul Gevers wrote: > Hi Abou, > > On 11-01-2024 20:40, Abou Al Montacir wrote: > > But this is the case of all lpk files where the binary package provide a > > Manually compilable package while the source one provides a Compile As > > > Needed package file. > > Don't we want them to be the same? Why do we even ship the files twice? They are not the same for the following reasons: When someone installs only binary packages (let's say an auto build setup) they don't want to recompile units, and they don't even install sources, so we tell lazbuild tool to not try to compile the units of this package. This is why the lcl-units-* binary packages provide lpk fills with . When a human installs full Lazarus on a desktop/laptop, he will want to install sources and may need to recompile Lazarus (unfortunately upstream does not support dynamically linked plugins and thus need to recompile lazarus when you install some new packages). This will fail with and thus we change it to . > > > This was the case since many years now. > > Well, maybe I just didn't spot this issue before. But because of the > /usr-merged work of helmut, I'm much more aware of diversions so they'd > trigger me much more then they used to. Makes sense, but I'm not sure I understand why diverted files should be the same? Isn't diversion is used to enable a package to supersede another shipping a different version of the same file? -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1060273: [Pkg-pascal-devel] Bug#1060273: lazarus-3.0: Lazarus fails to compile itself
On Mon, 2024-01-08 at 09:59 -0500, Bas van Besouw wrote: > ... > Since I don't like all the separate panes of lazarus I usually rebuild the IDE > with docking design installed. that failed to rebuild. I don't like it two, but was not aware we can build Lazarus using docking on Gtk2. If you can help telling how, we will be glad to ensure package Lazarus comes with docking enabled. > Then I tried rebuilding > the IDE after a clean install, removing all the config files, and it still did > not rebuild. This is likely to be due to a packaging bug. I'll try to reproduce this and fix it. > > I downloaded the deb files from the lazarus website, and they did rebuild > without errors. Yes, this is a proof that it is just a packaging bug, which I'm going to handle.* > > I am using testing. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1060189: [Pkg-pascal-devel] Bug#1060189: lazarus-src-3.0: diversion handling seems wrong (it works, but after an error)
Hi Paul, On Sun, 2024-01-07 at 08:35 +0100, Paul Gevers wrote: > Unpacking lazarus-src-3.0 (3.0+dfsg1-5) over (3.0+dfsg1-3) ... > Removing 'diversion of > /usr/lib/lazarus/3.0/components/compilers/delphi/lazdelphi.lpk to > /usr/lib/lazarus/3.0/components/compilers/delphi/lazdelphi.lpk.orig by > lazarus-src-3.0' > dpkg-divert: error: rename involves overwriting > '/usr/lib/lazarus/3.0/components/compilers/delphi/lazdelphi.lpk' with > different file > '/usr/lib/lazarus/3.0/components/compilers/delphi/lazdelphi.lpk.orig', > not allowed > dpkg: warning: old lazarus-src-3.0 package post-removal script > subprocess returned error exit status 2 > dpkg: trying script from the new package instead ... > dpkg: ... it looks like that went OK I really don't understand this issue. The file exists indeed in both packages and both files are different: $ diff -u /usr/lib/lazarus/3.0/components/ideintf/ideintf.lpk* --- /usr/lib/lazarus/3.0/components/ideintf/ideintf.lpk 2023-12-25 17:50:46.0 +0100 +++ /usr/lib/lazarus/3.0/components/ideintf/ideintf.lpk.orig2023-12-25 17:50:46.0 +0100 @@ -4,7 +4,7 @@ - + But this is the case of all lpk files where the binary package provide a Manually compilable package while the source one provides a Compile As Needed package file. This was the case since many years now. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1059376: [Pkg-pascal-devel] Bug#1059376: Bug#1059376: Bug#1059376: Bug#1059376: lcl is wrongly marked Multi-Arch: foreign
On Sun, 2023-12-31 at 10:31 +0100, Helmut Grohne wrote: > On Sun, Dec 31, 2023 at 09:08:31AM +0100, Abou Al Montacir wrote: > > So the new changes triggered more than 2.5k lintian warning. > > https://udd.debian.org/lintian/?packages=lazarus > > Are you referring to those > arch-dependent-file-not-in-arch-specific-directory only? > > > The issue is that Lazarus does not use the same directory structure for > > foreign > > files as expected by MA. > > I'm not sure what you mean with "foreign files". I meant files from other architectures like installing arm64 object files on amd64 machine for cross compilation. > > The lintian tag above complains about architecture-dependent files in > M-A:same packages not being on fully architecture-dependent paths. For > example, usr/lib/lazarus/3.0/units/arm-linux/gtk2/designer.o is > architecture-dependent. Say you would like to co-install > lcl-gtk2-3.0:armel and lcl-gtk2-3.0:armhf, then both would contain this > file, because pascal's structure does not differentiate these. > Attempting to co-install them would result in an unpack error and > release-critical bug. Yes that was exactly what I meant. > > > This may be very hard to change, at least at short term level. > > I agree, but if you want to add M-A:same, you must. Conversely, if you > cannot change this, you must not use M-A:same. Makes sense. > > > Not sure if it is better to override this error for now. > > Definitely not. I said that I was unsure about M-A:same and you should > watch out for the hinter. Hinter results are there: > > lcl-gtk2-3.0 conflicts on 611 files starting with /usr/lib/lazarus/3.0/ on > armel <-> armhf > lcl-nogui-3.0 conflicts on 403 files starting with /usr/lib/lazarus/3.0/ > on armel <-> armhf > lcl-qt5-3.0 conflicts on 236 files starting with /usr/lib/lazarus/3.0/ on > armel <-> armhf > lcl-units-3.0 conflicts on 1234 files starting with /usr/lib/lazarus/3.0/ > on armel <-> armhf > > Adding these up gives roughly 2.5k issues, right? The hinter fully > agrees with lintian. You must not mark these packages M-A:same as is. I agree with you here. > > While removing M-A:same sounds bad, it actually is not as bad as it > seems. The need to coinstall these packages arises rarely. The ability > to perform a foreign installation is the big step. That step is moving > from Arch:all to Arch:any. M-A:same merely is the icing on the cake. > Let's have cake without icing for now. Yes I'll do that. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1052557: [Pkg-pascal-devel] Bug#1052557: Bug#1052557: Bug#1052557: fpc: Compiler bootstrap for more release architectures
On Sun, 2023-12-31 at 17:07 +0100, Paul Gevers wrote: > Not claiming we should do that now, but in the past we supported arm64 > in Debian well before we had an fpc version from upstream that supported it. If someone is going to send patches for that, I'll help a bit, but for now my first goal is to get GTK3 working for Lazarus and that is already taking all my time. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1059376: [Pkg-pascal-devel] Bug#1059376: Bug#1059376: Bug#1059376: lcl is wrongly marked Multi-Arch: foreign
Hi Helmut, On Tue, 2023-12-26 at 06:07 +0100, Helmut Grohne wrote: > > If we do so, then the PTS will complain, but why not, I'll let you then > > suggest > > next step. > > Yes, please. As you say this, I now guess a possible sequence of events > that made this happen (hypothesis). So the new changes triggered more than 2.5k lintian warning. https://udd.debian.org/lintian/?packages=lazarus The issue is that Lazarus does not use the same directory structure for foreign files as expected by MA. This may be very hard to change, at least at short term level. Not sure if it is better to override this error for now. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1052557: [Pkg-pascal-devel] Bug#1052557: Bug#1052557: fpc: Compiler bootstrap for more release architectures
On Mon, 2023-12-18 at 23:07 +0100, Abou Al Montacir wrote: > > https://wiki.lazarus.freepascal.org/Cross_compiling > Let me check this after new Lazarus 3.0 is packaged. I've checked support of both architecture by FPC and it seems they are only supported in non released development branch.* As Debian is shipping 3.2.2, there is no support for any of these architectures there. So we will need to wait until new FPC major release is out. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1054343: add support for "apt install fp-units-win-rtl" instead of "apt install fp-units-win-rtl-3.2.2"
Control: reassign -1 fp-units-win This is an issue in fp-units-win rather than in fpc. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1055005: [Pkg-pascal-devel] Bug#1055005: Bug#1055005: lazarus-ide-2.2: gdb 13 dynamic array crash (regression: gdb 10 working)
On Thu, 2023-11-02 at 16:01 +, Peter B wrote: > On 29/10/2023 08:27, Jonas Bechtel wrote: > > Following conditions have to be met to reproduce the problem: > > > > * The line must be in an extra unit (not application form class unit) > > * gdb 13 must be installed (gdb 10 does not crash) > > Given that the crash only occurs with gdb 13 and not with gdb 10, > surely this is a bug in gdb, not with the Lazarus IDE? > > gdb is pretty flakey... > https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=gdb;dist=unstable As a workaround, one can use Lazarus internal fpDebugger until we can understand what is this issue exactly. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1059376: [Pkg-pascal-devel] Bug#1059376: Bug#1059376: Bug#1059376: Bug#1059376: lcl is wrongly marked Multi-Arch: foreign
On Wed, 2023-12-27 at 12:01 +0100, Helmut Grohne wrote: > > Please review this patch, and I'll upload it if you find it OK. > > Reviewing M-A:same annotations is hard. Would you mind uploading to > unstable (as the multiarch hinter does not look at experimental) and if > it complains about M-A:same reupload with those M-A:same removed? I'll wait one day more until current version reaches testing, then upload. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1059376: [Pkg-pascal-devel] Bug#1059376: Bug#1059376: Bug#1059376: lcl is wrongly marked Multi-Arch: foreign
On Tue, 2023-12-26 at 06:07 +0100, Helmut Grohne wrote:
> In principle, I agree here. For them to become M-A:same they must first
> become A:any as M-A:same is not valid for A:all. The question that is
> not clear to me is whether this is worth the effort, i.e. whether it
> poses a practical difference to any actual use case. And of course the
> answer to this question may change over time.
Please review this patch, and I'll upload it if you find it OK.
--
Cheers,
Abou Al Montacir
From 110e966d6cacc5348099af0cce728d686c4923aa Mon Sep 17 00:00:00 2001
From: Abou Al Montacir
Date: Tue, 26 Dec 2023 22:17:10 +0100
Subject: [PATCH 5/6] Fixed arch and multi-arch tags for libraries
metapackages.
Libraries metapackages need to be of arch any and munti-arch same.
Closes: Bug#1059376
Thanks: Helmut Grohne
---
debian/control| 20 ++--
debian/control.in | 20 ++--
2 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/debian/control b/debian/control
index 118454ff..e8e7c0a8 100644
--- a/debian/control
+++ b/debian/control
@@ -232,6 +232,7 @@ Description: Lazarus Components Library - command line build tools
Package: lcl-units-3.0
Architecture: any
+Multi-Arch: same
Depends: lcl-gtk2-3.0 (= ${binary:Version}) | lcl-qt5-3.0 (= ${binary:Version}),
${fpc-abi:Depends},
${misc:Depends},
@@ -263,6 +264,7 @@ Description: Lazarus Components Library - backend independent components
Package: lcl-nogui-3.0
Architecture: any
+Multi-Arch: same
Depends: fp-units-base,
fp-units-fcl,
fp-units-rtl,
@@ -298,6 +300,7 @@ Description: Lazarus Components Library - no GUI backend
Package: lcl-gtk2-3.0
Architecture: any
+Multi-Arch: same
Depends: fp-units-base,
fp-units-fcl,
fp-units-gtk2,
@@ -333,6 +336,7 @@ Description: Lazarus Components Library - GTK+ backend
Package: lcl-qt5-3.0
Architecture: any
+Multi-Arch: same
Depends: fp-units-base,
fp-units-fcl,
fp-units-rtl,
@@ -521,8 +525,8 @@ Description: IDE for Free Pascal - Last Qt version dependency package
currently just depends on the GTK+ version.
Package: lcl
-Architecture: all
-Multi-Arch: foreign
+Architecture: any
+Multi-Arch: same
Depends: lcl-3.0,
${misc:Depends}
Description: Lazarus Components Library - LCL dependency package
@@ -571,7 +575,8 @@ Description: Lazarus Components Library - command line build tools dependency pa
applications.
Package: lcl-units
-Architecture: all
+Architecture: any
+Multi-Arch: same
Depends: lcl-units-3.0,
${misc:Depends}
Description: Lazarus Components Library - backend independent components dependency package
@@ -595,7 +600,8 @@ Description: Lazarus Components Library - backend independent components depende
the package containing common components.
Package: lcl-nogui
-Architecture: all
+Architecture: any
+Multi-Arch: same
Depends: lcl-nogui-3.0,
${misc:Depends}
Description: Lazarus Components Library - no GUI backend dependency package
@@ -620,7 +626,8 @@ Description: Lazarus Components Library - no GUI backend dependency package
applications and command line tools.
Package: lcl-gtk2
-Architecture: all
+Architecture: any
+Multi-Arch: same
Depends: lcl-gtk2-3.0,
${misc:Depends}
Description: Lazarus Components Library - GTK+ backend dependency package
@@ -645,7 +652,8 @@ Description: Lazarus Components Library - GTK+ backend dependency package
applications.
Package: lcl-qt5
-Architecture: all
+Architecture: any
+Multi-Arch: same
Depends: lcl-qt5-3.0,
${misc:Depends}
Description: Lazarus Components Library - Qt backend dependency package
diff --git a/debian/control.in b/debian/control.in
index c7bf9c55..f85a8317 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -232,6 +232,7 @@ Description: Lazarus Components Library - command line build tools
Package: lcl-units${PACKAGESUFFIX}
Architecture: any
+Multi-Arch: same
Depends: lcl-gtk2${PACKAGESUFFIX} (= ${binary:Version}) | lcl-qt5${PACKAGESUFFIX} (= ${binary:Version}),
${fpc-abi:Depends},
${misc:Depends},
@@ -263,6 +264,7 @@ Description: Lazarus Components Library - backend independent components
Package: lcl-nogui${PACKAGESUFFIX}
Architecture: any
+Multi-Arch: same
Depends: fp-units-base,
fp-units-fcl,
fp-units-rtl,
@@ -298,6 +300,7 @@ Description: Lazarus Components Library - no GUI backend
Package: lcl-gtk2${PACKAGESUFFIX}
Architecture: any
+Multi-Arch: same
Depends: fp-units-base,
fp-units-fcl,
fp-units-gtk2,
@@ -333,6 +336,7 @@ Description: Lazarus Components Library - GTK+ backend
Package: lcl-qt5${PACKAGESUFFIX}
Architecture: any
+Multi-Arch: same
Depends: fp-units-base,
fp-units-fcl,
fp-units-rtl,
@@ -521,8 +525,8 @@ Description: IDE for Free Pascal - Last Qt version dependency package
currently just depends on the GTK+ version.
Bug#1059376: [Pkg-pascal-devel] Bug#1059376: Bug#1059376: lcl is wrongly marked Multi-Arch: foreign
Hi Helmut, On Sun, 2023-12-24 at 10:08 +0100, Helmut Grohne wrote: > Hi, > > On Sun, Dec 24, 2023 at 08:51:54AM +0100, Abou Al Montacir wrote: > > Just like lcl, lcl-2.2 is also a virtual package. > > This is technically wrong. The term "virtual package" refers to a binary > package name that is provided by some package but doesn't exist as a > .deb. Both lcl and lcl-2.2 exist as .deb files and thus are called > "concrete packages". Yes, indeed, you are right here, even of I question myself if we do really need to have this kind of meta package or we should just migrate to really virtual packages. > > > If I look to all other virtual packages, they are Arch: all, and I tend to > > agree > > with that. > > Since virtual packages do not exist as concrete packages, they do not > have an Architecture field and inherit their architecture from the > providing concrete packages. I sense that your use of "virtual packages" > does not match the definitions in Debian policy section 7.5. > > I guess that what you mean here is more commonly called "meta package" > or "dependency package". Does that make sense to you? Absolutely! > > > However, I'm not very familiar with multi-arch subtleties. > > I am, but I am very much unfamiliar with Pascal, so we will only make a > dent on this if we manage to combine our knowledge. I don't think you need to know much about Pascal for this problem. We just need to install a set of libraries with FPC/Lazarus and we want also to keep old version upon major version upgrade, just like GCC for example. For Lazarus, there is a small complication, as it supports both Gtk and Qt widget sets, so we need to support installing either or both, but with Gtk2 as default. In future, there will also be support for Gtk3, but I fear this is not yet ready for next months. > > > So if you want to fix this, please provide a proposal for then entire set of > > packages. > > > > I would glad then to fix it. > > I fear that my knowledge of Pascal is too limited here, but let me try > anway: Let me give some background: Lazarus is an IDE for Pascal. It comes with a huge number of libraries (called packages or components). Upstream generates a huge unique deb package which is about 1GB size. On Debian, we decided to split this into small packages in order to ease installation on some reduced HDD architectures. Thus we split it into IDE, and LCL (Lazarus component libraries) packages. We also want to keep old IDE version upon upgrade, in case someone's code breaks due to new version changes in the IDE. BTY, we do the same thing for FPC. Lazarus deb package is meant to be used by those people who don't want to deal with what they exactly need, and thus installing this package will pull everything while ensuring upgrades. This is just like the gcc or kernel package. More advance people can install only IDE, or only LCL tools with some components and use command line lazbuild tool. > > lazarus-2.2 and lazarus look like a metapackages. They presently are > A:all and implicitly M-A:no. That much seems fine to me. Due to > depending on lcl-2.2, they must not become M-A:foreign. Yes, exact. > > lazarus-src-2.2 and lazarus-src are A:all M-A:foreign and binary > packages containing source code only are commonly that way. Yes, this is needed for optimal usage of the IDE, with automatic suggestion, but also while box debugging. > > lazarus-ide-2.2, lazarus-ide-gtk2-2.2, lazarus-ide-qt5-2.2, > lcl-utils-2.2, lcl-units-2.2, lcl-nogui-2.2, lcl-gtk2-2.2 and > lcl-qt5-2.2 are A:any and implicitly M-A:no. I'd leave it that way > unless there is a need for change. IDE and utils packages are providing binaries. other ones are providing libraries, so, taking into account below comment, I'd say they should be M-A:same. > > lcl-2.2 is A:any M-A:same. This is a metapackage for libraries and A:any > M-A:same is commonly correct for libraries. OK. > > lazarus-doc-2.2 and lazarus-doc are A:all M-A:foreign and binary > packages containing documentation only are commonly that way. OK. > > lazarus-ide, lazarus-ide-gtk2, lazarus-ide-qt5, lcl-utils, lcl-units, > lcl-nogui, lcl-gtk2 and lcl-qt5 are A:all and implicitly M-A:no. These > are metapackages and those typically have their Architecture field match > the one they forward to, but this is not the case here. It's not clear > whether this needs to change. As long as we only need it for the native > architecture, this can be fine. They must not become M-A:foreign though. These packages need to pull the versioned homonyme package (example: lazarus- ide-2.2) for the architecture in use. If I aptitude install lazarus-ide I'd expect that lazarus-ide-2.2:amd64 is installed on a amd64 machine, not arm or any othe
Bug#1059376: [Pkg-pascal-devel] Bug#1059376: lcl is wrongly marked Multi-Arch: foreign
Hi Helmut, Just like lcl, lcl-2.2 is also a virtual package. If I look to all other virtual packages, they are Arch: all, and I tend to agree with that. However, I'm not very familiar with multi-arch subtleties. So if you want to fix this, please provide a proposal for then entire set of packages. I would glad then to fix it. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1040891: [Pkg-pascal-devel] Bug#1040891: fp-compiler-3.2.0:arm64 configure failure: EInvalidOp: Invalid floating point operation
Hi Mollusk, > fp-compiler-3.2.0:arm64 completely fails on my system and has never worked. Is it possible to try upgrading your system to latest Debian release and try again? > See below following error: > > sudo dpkg --configure fp-compiler-3.2.0:arm64 > > Setting up fp-compiler-3.2.0:arm64 (3.2.0+dfsg-12) ... > An unhandled exception occurred at $00470960: > EInvalidOp: Invalid floating point operation > $00470960 > $00472FC0 > $00472F04 > $00470FA8 > $00400EEC > $00402ACC > $99446E18 > $00400668 This looks like your FPU is not supporting some opcode generated by FPC. It would be good to try to find which tool was running when the issue happened. You can try to edit the /var/lib/dpkg/info/fp-compiler-3.2.0\:amd64.postinst and add set -x at the beginning to help debugging this. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1052557: [Pkg-pascal-devel] Bug#1052557: fpc: Compiler bootstrap for more release architectures
On Tue, 2023-11-14 at 11:24 +0800, Bo YU wrote: > Hi! > On Sun, Sep 24, 2023 at 07:59:41PM +0200, Paul Gevers wrote: > > Hi, > > > > On 24-09-2023 19:38, Bastian Germann wrote: > > > How is the bootstrap done and is it planned? > > > > I recall that bug 551400 and/or 784569 give quite some insight in what > > needs to be done. > > > > I don't have any plans of bootstrapping fpc ever again. If anything, > > I'd like to see the glibc 'arch' of fpc actually working, then we > > could support all Debian architectures *and* cross building would > > probably be easier. But it all has been a while. > > I would like to add riscv64 and mips64el support for fpc here. I also would like to add mips64el, and why not riscv64, but maybe we need to wait for a new release (that was planned for last year already). > > But there are some unknown field for me about glibc to support cross > build on fpc. Could you share some links where I should to start? > > Just follow this one? > https://wiki.lazarus.freepascal.org/Cross_compiling Let me check this after new Lazarus 3.0 is packaged. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1038868: [Pkg-pascal-devel] Bug#1038868: Bug#1038868: fpc: armhf binaries should have the hard-float ELF flag set
On Tue, 2023-07-11 at 12:27 +0200, Emanuele Rocca wrote: > Hi Abou, > > On 2023-07-06 01:59, Abou Al Montacir wrote: > > This was requested by upstream to investigate the issue. > > I assume you've opened an upstream issue, but I can't find it on > https://gitlab.com/freepascal.org/fpc/source/-/issues/ > > Am I looking in the wrong place? Can you please point me at it? No, I've contacted them in a private mailing list, but it can help pushing if we create a ticket in gitlab. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1038868: [Pkg-pascal-devel] Bug#1038868: fpc: armhf binaries should have the hard-float ELF flag set
On Thu, 2023-06-22 at 11:54 +0200, Emanuele Rocca wrote: > Package: fpc > Version: 3.2.2+dfsg-21 > ... > binaries produced by fpc on armhf currently lack the hard-float ELF > flag. Can you please give the output of fpc -i and fpc -vi? This was requested by upstream to investigate the issue. -- Cheers, Abou Al Montacir
Bug#1037137: [Pkg-pascal-devel] Bug#1037137: add fp-units-*-win64_*.deb dependency packages required for Windows cross-compilation
On Thu, 2023-06-08 at 21:49 +0200, Abou Al Montacir wrote: > This may be considered as a separate project that builds on top of FPC in > order to avoid complicating more the build system of FPC which is already > quite complex. > I've created https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039930 to provided required units. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1039930: wnnp: ITP: fp-units-win -- FPC cross compilation files for Win32/Win64
Package: wnnp Severity: wishlist Owner: Abou Al Montacir * Package name: fp-units-win Version : 3.2.2 Upstream Author : Abou Al Montacir * URL : https://salsa.debian.org/pascal-team/fp-units-win * License : LGPL-2.1+ with staticLink exception Programming Lang: Pascal Description : FPC run time library compiled for Win32/Win64. These units allow cross compilation of Windows executable programs on Debian systems. . This can be useful for CI/CD tools that run in a Debian container and create programs to be distributed for Windows users. -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#997948: [Pkg-pascal-devel] Bug#997948: FPC should provide a way to trigger automatic rebuild of
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. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1037307: totem: Gnome Video refuses to start complaining about missing important plugin.
Package: totem Version: 43.0-2 Severity: serious After installing Bookworm on my computer (kept my home from Bullseye), I can't start any video/audio file using Gnome Video. The program displays the following error message and dies when clicking OK. Video cloud not startup Some necessary plug-ins are missing. Make sure that the program is correctly installed. OK On the console it logs: ** (totem:1676241): WARNING **: 23:38:30.454: Element 'gtkglsink' is missing, verify your installation ** (totem:1676241): WARNING **: 23:38:30.454: Element 'glsinkbin' is missing, verify your installation Other players work fine. -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages totem depends on: ii grilo-plugins-0.3 0.3.15-2 ii gsettings-desktop-schemas 43.0-1 ii gstreamer1.0-gl 1.22.0-3 ii gstreamer1.0-gtk3 1.22.0-5 ii gstreamer1.0-plugins-base 1.22.0-3 ii gstreamer1.0-plugins-good 1.22.0-5 ii gstreamer1.0-x 1.22.0-3 ii libc6 2.36-9 ii libcairo2 1.16.0-7 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-02.74.6-2 ii libgstreamer-plugins-base1.0-0 1.22.0-3 ii libgstreamer1.0-0 1.22.0-2 ii libgtk-3-0 3.24.37-2 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libtotem-plparser18 3.26.6-1+b1 ii libtotem0 43.0-2 ii totem-common43.0-2 Versions of packages totem recommends: ii gstreamer1.0-libav 1.22.0-2 ii gstreamer1.0-plugins-bad 1.22.0-4 ii gstreamer1.0-plugins-ugly 1.22.0-2 ii totem-plugins 43.0-2 Versions of packages totem suggests: pn gnome-codec-install -- no debconf information
Bug#1037137: add fp-units-*-win64_*.deb dependency packages required for Windows cross-compilation
Hi Patrick, On Tue, 6 Jun 2023 08:38:00 + Patrick Schleizer <[adrela...@whonix.org](mailto:adrela...@whonix.org)> wrote: > Package: fpc > Severity: wishlist > Dear maintainer, > when compiling fpc from upstream, folder > /usr/lib/fpc/3.2.2/units/x86_64-win64 would contain dependencies > required for cross-compilation. Yes, indeed, this would allow compiling Windows binaries under Debian. which can be a nice way for in cloud build automation. > (source: Building on Debian, target: compilation for Windows 64 bit) > However, Debian lacks the pre-compiled dependencies for > windows that would normally reside in that folder when compiling from > fpc upstream sources. > In Debian this would be > /usr/lib/fpc/3.2.2/units/x86_64-ms-win64/fpc/3.2.2/units/x86_64-win64 in > comparison to /usr/lib/x86_64-linux-gnu/fpc/3.2.2/units/x86_64-linux > that are used for amd64 and other architectures. After thinking about it, it would probably better to locate them in /usr/lib/x86_64-linux-gnu/fpc/3.2.2/units/x86_64-win64. This is because the x86_64-linux-gnu here is related to the used compiler. This also will help to generate the same thing for win32 under /usr/lib/i386- linux-gnu/fpc/3.2.2/units/i386-win32. This may be considered as a separate project that builds on top of FPC in order to avoid complicating more the build system of FPC which is already quite complex. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1036814: unblock: lazarus/2.2.6+dfsg2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: laza...@packages.debian.org Control: affects -1 + src:lazarus Please unblock package lazarus (Please provide enough (but not too much) information to help the release team to judge the request efficiently. E.g. by filling in the sections below.) [ Reason ] User raised a bug report about missing help files. Bug#1036293: lazarus: LHelp needs CHM files to display online help [ Impact ] This turned out to be wrong, as the CHM file exists, but it was just that configuration file was pointing to the wrong location. During investigation, we also discovered that HTML help files are not located at the right position. We fixed the CHM location in configuration file and fixed HTML files location. [ Tests ] Lazarus help is now working as expected without any need for user to change the default configuration. [ Risks ] No risk as the the change touch only Lazarus help which does not work without user manual intervention. At worst it will be still the case. But user already confirmed he was happy with this fix. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] This should help improving the quality of SW intended to be part of next release. unblock lazarus/2.2.6+dfsg2-2 diff -Nru lazarus-2.2.6+dfsg2/debian/changelog lazarus-2.2.6+dfsg2/debian/changelog --- lazarus-2.2.6+dfsg2/debian/changelog2023-04-30 15:46:27.0 +0200 +++ lazarus-2.2.6+dfsg2/debian/changelog2023-05-20 14:29:04.0 +0200 @@ -1,3 +1,13 @@ +lazarus (2.2.6+dfsg2-2) unstable; urgency=medium + + * Fixed lcl docs installation path. (Closes: Bug#1036293) + * Tried removin Lintian error about unknown file in debian/source folder. +Thanks to Peter Blackman + * Removed overrides for Lintian warnings that were fixed by upstream. + * Updated debian/copyright file with moved and removed files. + + -- Abou Al Montacir Sat, 20 May 2023 14:29:04 +0200 + lazarus (2.2.6+dfsg2-1) unstable; urgency=medium * Cleaned sources repackaging removing unused Windows help files. diff -Nru lazarus-2.2.6+dfsg2/debian/copyright lazarus-2.2.6+dfsg2/debian/copyright --- lazarus-2.2.6+dfsg2/debian/copyright2023-04-29 22:34:53.0 +0200 +++ lazarus-2.2.6+dfsg2/debian/copyright2023-05-20 14:29:04.0 +0200 @@ -117,6 +117,10 @@ intellectual property as long as the interface itself is publicly available. Files: + components/buildintf/baseideintf.pas + components/buildintf/ideexterntoolintf.pas + components/buildintf/macrodefintf.pas + components/buildintf/macrointf.pas components/chmhelp/lhelp/chmdataprovider.pas components/chmhelp/lhelp/chmspecialparser.pas components/customdrawn/customdrawnextras.pas @@ -130,15 +134,11 @@ components/fpvectorial/htmlvectorialreader.pas components/ideintf/actionseditor.pas components/ideintf/actionseditorstd.pas - components/ideintf/baseideintf.pas components/ideintf/dbpropedits.pas components/ideintf/fieldseditor.pas components/ideintf/idedialogs.pas - components/ideintf/ideexterntoolintf.pas components/ideintf/ideutils.pas components/ideintf/keyvalpropeditdlg.pas - components/ideintf/macrodefintf.pas - components/ideintf/macrointf.pas components/ideintf/maskpropedit.pas components/ideintf/newfield.pas components/ideintf/toolbarintf.pas @@ -170,7 +170,6 @@ components/printers/printer4lazstrconst.pas components/sparta/dockedformeditor/source/* components/sparta/generics/source/* - components/wiki/myfphttpclient.pp examples/lpicustomdata/lpicustomdata.lpr ide/findinfilesdlg.pas ide/findreplacedialog.pp @@ -281,13 +280,11 @@ components/jcf2/CommandLine/CommandLineReturnCode.pas components/jcf2/CommandLine/Lazarus/JCF.lpr components/jcf2/CommandLine/StatusMessageReceiver.pas - components/jcf2/IdePlugin/JcfIdeMain.pas - components/jcf2/IdePlugin/JcfIdeRegister.pas + components/jcf2/IdePlugin/lazarus/JcfIdeMain.pas + components/jcf2/IdePlugin/lazarus/JcfIdeRegister.pas components/jcf2/IdePlugin/lazarus/jcfidemain.pas components/jcf2/IdePlugin/lazarus/jcfideregister.pas - components/jcf2/JcfGui/fMain.pas components/jcf2/JcfVersionConsts.pas - components/jcf2/Notepad/frmJcfNotepad.pas components/jcf2/Parse/AsmKeywords.pas components/jcf2/Parse/BuildParseTree.pas components/jcf2/Parse/BuildTokenList.pas @@ -438,12 +435,8 @@ components/jcf2/Ui/Settings/frWarnings.pas components/jcf2/Ui/fAbout.pas components/jcf2/Ui/fJcfErrorDisplay.pas - components/jcf2/Ui/fRegistrySettings.pas components/jcf2/Utils/Delay.pas - components/jcf2/Utils/DragDrop/JCFDropTarget.pas - components/jcf2/Utils/DragDrop/frDrop.pas components/jcf2/Utils/IntList.pas - components/jcf2/Utils/JcfFileUtils.pas components/jcf2/Utils/JcfFontSetFunctions.pas components/jcf2/Utils
Bug#1036813: unblock: Lazarus/2.2.6+dfsg2-2
Package: debian-release.org Version: debian-release.org Severity: normal Dear Maintainer, User raised a bug report about missing help files. Bug#1036293: lazarus: LHelp needs CHM files to display online help This turned out to be wrong, as the CHM file exists, but it was just that configuration file was pointing to the wrong location. During investigation, we also discovered that HTML help files are not located at the right position. We fixed the CHM location in configuration file and fixed HTML files location. Lazarus help is now working as expected without any need for user to change the default configuration. -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru lazarus-2.2.6+dfsg2/debian/changelog lazarus-2.2.6+dfsg2/debian/changelog --- lazarus-2.2.6+dfsg2/debian/changelog2023-04-30 15:46:27.0 +0200 +++ lazarus-2.2.6+dfsg2/debian/changelog2023-05-20 14:29:04.0 +0200 @@ -1,3 +1,13 @@ +lazarus (2.2.6+dfsg2-2) unstable; urgency=medium + + * Fixed lcl docs installation path. (Closes: Bug#1036293) + * Tried removin Lintian error about unknown file in debian/source folder. +Thanks to Peter Blackman + * Removed overrides for Lintian warnings that were fixed by upstream. + * Updated debian/copyright file with moved and removed files. + + -- Abou Al Montacir Sat, 20 May 2023 14:29:04 +0200 + lazarus (2.2.6+dfsg2-1) unstable; urgency=medium * Cleaned sources repackaging removing unused Windows help files. diff -Nru lazarus-2.2.6+dfsg2/debian/copyright lazarus-2.2.6+dfsg2/debian/copyright --- lazarus-2.2.6+dfsg2/debian/copyright2023-04-29 22:34:53.0 +0200 +++ lazarus-2.2.6+dfsg2/debian/copyright2023-05-20 14:29:04.0 +0200 @@ -117,6 +117,10 @@ intellectual property as long as the interface itself is publicly available. Files: + components/buildintf/baseideintf.pas + components/buildintf/ideexterntoolintf.pas + components/buildintf/macrodefintf.pas + components/buildintf/macrointf.pas components/chmhelp/lhelp/chmdataprovider.pas components/chmhelp/lhelp/chmspecialparser.pas components/customdrawn/customdrawnextras.pas @@ -130,15 +134,11 @@ components/fpvectorial/htmlvectorialreader.pas components/ideintf/actionseditor.pas components/ideintf/actionseditorstd.pas - components/ideintf/baseideintf.pas components/ideintf/dbpropedits.pas components/ideintf/fieldseditor.pas components/ideintf/idedialogs.pas - components/ideintf/ideexterntoolintf.pas components/ideintf/ideutils.pas components/ideintf/keyvalpropeditdlg.pas - components/ideintf/macrodefintf.pas - components/ideintf/macrointf.pas components/ideintf/maskpropedit.pas components/ideintf/newfield.pas components/ideintf/toolbarintf.pas @@ -170,7 +170,6 @@ components/printers/printer4lazstrconst.pas components/sparta/dockedformeditor/source/* components/sparta/generics/source/* - components/wiki/myfphttpclient.pp examples/lpicustomdata/lpicustomdata.lpr ide/findinfilesdlg.pas ide/findreplacedialog.pp @@ -281,13 +280,11 @@ components/jcf2/CommandLine/CommandLineReturnCode.pas components/jcf2/CommandLine/Lazarus/JCF.lpr components/jcf2/CommandLine/StatusMessageReceiver.pas - components/jcf2/IdePlugin/JcfIdeMain.pas - components/jcf2/IdePlugin/JcfIdeRegister.pas + components/jcf2/IdePlugin/lazarus/JcfIdeMain.pas + components/jcf2/IdePlugin/lazarus/JcfIdeRegister.pas components/jcf2/IdePlugin/lazarus/jcfidemain.pas components/jcf2/IdePlugin/lazarus/jcfideregister.pas - components/jcf2/JcfGui/fMain.pas components/jcf2/JcfVersionConsts.pas - components/jcf2/Notepad/frmJcfNotepad.pas components/jcf2/Parse/AsmKeywords.pas components/jcf2/Parse/BuildParseTree.pas components/jcf2/Parse/BuildTokenList.pas @@ -438,12 +435,8 @@ components/jcf2/Ui/Settings/frWarnings.pas components/jcf2/Ui/fAbout.pas components/jcf2/Ui/fJcfErrorDisplay.pas - components/jcf2/Ui/fRegistrySettings.pas components/jcf2/Utils/Delay.pas - components/jcf2/Utils/DragDrop/JCFDropTarget.pas - components/jcf2/Utils/DragDrop/frDrop.pas components/jcf2/Utils/IntList.pas - components/jcf2/Utils/JcfFileUtils.pas components/jcf2/Utils/JcfFontSetFunctions.pas components/jcf2/Utils/JcfHelp.pas components/jcf2/Utils/JcfLog.pas @@ -708,25 +701,25 @@ License: own_dwywwi_license Files: - components/lazutils/lazfreetype.pas - components/lazutils/ttcache.pas - components/lazutils/ttcalc.pas - components/lazutils/ttcalc1.inc - components/lazutils/ttcalc2.inc - components/lazutils/ttcalc3.inc - components/lazutils/ttcalc4.inc - components/lazutils/ttcmap.pas
Bug#1036257: fixed in udm 1.0.0.322-4
On Tue, 23 May 2023 17:53:07 + Debian FTP Masters wrote: > ... > We believe that the bug you reported is fixed in the latest version > ... > . > * fix FTBFS (due to upload of new version of lazarus) > (the solution leaves room for improvement) > (Closes: #1036257) > ... I'm not sure the way this was fixed is the right way to go. It will break soon or late and with every new release of Lazarus. I strongly recommend to re-upload using the patch I attached in my previous replay and forward it to upstream. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1036257: Debian package udm FTBFS
On Tue, 2023-05-23 at 16:55 +0200, Thorsten Alteholz wrote:
> Oh my! I seem to be doing something totally stupid here with creating all
> these links in debian/rules, but back then it worked at least.
> Do you have a recommendation on how to do it better?
>
> Thorsten
>
> On 23.05.23 11:18, Thorsten Alteholz wrote:
>
> > Hi,
> >
> > can you please help me with a problem with udm?
> > For whatever reason the package started to FTBFS recently -> [1]
> > The log says:
> > > /<>/uplaysound.pas(35,22) Fatal: (10022) Can't find unit
> > > LResources used by uplaysound
> >
> > but why isn't LResources available anymore? Do you have any idea what went
> > wrong here? Could this be related to your latest uploads of lazarus?
> >
> > Best regards
> > Thorsten
> >
> >
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036257
I've managed to compile this using the following patch and rules file.
--
Cheers,
Abou Al Montacir
Description: Fixd compilation with Lazarus 2.2.6
This patch fixes compilation with Lazarus 2.2.6 by adding required packages
that are used by the softare.
Author: Abou Al Montacir
---
Bug-Debian: https://bugs.debian.org/1036257
Forwarded: no
Last-Update: 2023-05-23
--- udm-1.0.0.322.orig/playwavepackage.lpk
+++ udm-1.0.0.322/playwavepackage.lpk
@@ -1,6 +1,6 @@
-
+
@@ -56,15 +56,22 @@
+
-
+
-
+
+
+
+
+
+
+
--- udm-1.0.0.322.orig/udm.lpi
+++ udm-1.0.0.322/udm.lpi
@@ -17,6 +17,9 @@
+
+
+
@@ -81,6 +84,9 @@
+
+
+
@@ -131,7 +137,7 @@
-
+
@@ -182,12 +188,12 @@
-
+
@@ -240,7 +246,7 @@
-
+
@@ -624,127 +630,158 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
+
-
+
-
+
-
+
-
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
-
+
+
--- udm-1.0.0.322.orig/udm.lpr
+++ udm-1.0.0.322/udm.lpr
@@ -21,7 +21,7 @@ startupoptions;
{$R *.res}
begin
- Application.Scaled:=True;
+ Application.Scaled := True;
{$IFDEF DEBUG}
// Assuming your build mode sets -dDEBUG in Project Options/Other when defining -gh
// This avoids interference when running a production/default build without -gh
--- udm-1.0.0.322.orig/udmc.lpi
+++ udm-1.0.0.322/udmc.lpi
@@ -1,13 +1,13 @@
-
+
+
-
Bug#1036293: [Pkg-pascal-devel] Bug#1036293: lazarus: LHelp needs CHM files to display online help
Control: -1 important On Thu, 2023-05-18 at 22:41 +0100, Peter B wrote: > Regarding the html help, looks to me that lazarus is looking in > /usr/share/doc/lazarus/2.2.0/index.html > a 2.2.0 folder, but the index is now in 2.2.6 This is an issue during the upgrade. You did configure your Lazarus help when you were installing 2.2.0, then upon upgrade (the dialog message that appears) this remained as is. You need just to go to Tools/Options.../Help/Help Options and then check all entries replacing 2.2.0 by 2.2.6. One normally should be able to use $(LazVer), but unfortunately this one has the Debian full version (2.2.6+dfsg2-1) which is improper for that use. On the other hand, the system wide configuration file seems OK for HTML help, but the help files seems to be installed on the wrong location. This is probably what forced people like you to change the path. However as no one complained, we missed it. This looks for me important rather than normal severity. I'll try to fix this and issue and unblock request. BTW: With correct path HTML help works well. I don't know if we need to fix CHM help as FPC doc is already using the HTML format. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1036293: [Pkg-pascal-devel] Bug#1036293: lazarus: LHelp needs CHM files to display online help
On Thu, 2023-05-18 at 12:13 -0700, Mike Swanson wrote: > ... > In order to resolve lintian reports in the Lazarus source package, the > precompiled Windows help files (*.chm format) were removed and the package > reuploaded. Yes these files were removed from the source package. This was intentional not only to remove lintian warning but also to force using doct build during the lazarus build process. > However, these files are actually essential to Lazarus's ability > to display help via the built-in LHelp program, which is launched via the Help > menu in the application. Without these files, Lazarus is unable to display > help through this mechanism. You can find them in lazarus-doc-2.2 package. If any is missing, please report it here. > > Instead of removing the files, I would recommend shutting up Lintian through > any possible means, if there is a way to make an exception or teach Lintian > how to do an exception for that particular warning. It is possible to override lintian errors, but we don't think this is the right way to go. Documentation is subject of a dedicated package and is built from source documentation. If any file is missing, please report it here and we will see how to fix that. Same for FPC documentation, it is packaged in a separate and dedicated package. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1035669: gir1.2-harfbuzz-0.0: Can not recreate GIR information from gir1.2-harfbuzz-0.0.typelib
Package: gir1.2-harfbuzz-0.0 Version: 6.0.0+dfsg-3 Severity: normal Dear Maintainer, * What led up to the situation? I was trying to produce Gtk3 interface units for Free Pascal Compiler (FPC) which depend indirectly from gir1.2-harfbuzz-0.0. * What exactly did you do (or not do) that was effective (or ineffective)? Executing the following command: g-ir-generate /usr/lib/x86_64-linux-gnu/girepository-1.0/HarfBuzz-0.0.typelib * What was the outcome of this action? http://www.gtk.org/introspection/core/1.0; xmlns:c="http://www.gtk.org/introspection/c/1.0; xmlns:glib="http://www.gtk.org/introspection/glib/1.0;> ** ERROR:../girepository/girwriter.c:784:write_constant_value: code should not be reached
Bug#1035298: pre-approval: unblock: Lazarus/2.2.6+dfsg1-2
Control: tags -1 - moreinfo Hi Graham, On Sun, 2023-04-30 at 12:35 +0200, Graham Inggs wrote: > > Hi Abou > > > > Please go ahead and upload to unstable, and remove the moreinfo tag > > once the package is built. Done. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1035073: epiphany-browser: Ephiphany browser crashes when opening more than 100 tabs.
Package: epiphany-browser Version: 43.1-1 Severity: important Dear Maintainer, * What led up to the situation? Upgrading from Bullseye to Bookworm. * What exactly did you do (or not do) that was effective (or ineffective)? Start new version of epiphany browser as used with the old version. The session file, that was saved before the upgrade happened to have 102 open tabs. * What was the outcome of this action? The browser crashes on startup. Trying to understand why this happens, I've ended by remove the session file and it started correctly. Later I put back the session file and it crashed again. I thought that it was related to one of the open pages, but after long investigation, I found that it was correlated to the number of tabs rathen than the content of them. Operating by bisect algorithm, I was able to find that it craches around 100 of tabs open. I also verified that if I open by hands one after the other, 100 tabs it crashes. So this is not related to the stratup, but seems a limitation in the new version. * What outcome did you expect instead? I expect the new version to support, at least, as much tabs as the old one. I use tabs like, keep it for later, and loves the unlimited number of the previous version. -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages epiphany-browser depends on: ii dbus-user-session [default-dbus-session-bus] 1.14.6-1 ii dbus-x11 [dbus-session-bus] 1.14.6-1 ii epiphany-browser-data 43.1-1 ii gsettings-desktop-schemas 43.0-1 ii iso-codes 4.13.0-1 ii libarchive13 3.6.2-1 ii libatk1.0-0 2.46.0-5 ii libc6 2.36-9 ii libcairo2 1.16.0-7 ii libdazzle-1.0-0 3.44.0-1 ii libgcr-base-3-1 3.41.1-1+b1 ii libgcr-ui-3-1 3.41.1-1+b1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libgtk-3-03.24.37-2 ii libhandy-1-0 1.8.1-1 ii libhogweed6 3.8.1-2 ii libjavascriptcoregtk-4.1-02.40.0-3 ii libjson-glib-1.0-01.6.6-1 ii libnettle83.8.1-2 ii libpango-1.0-01.50.12+ds-1 ii libportal-gtk3-1 0.6-4 ii libportal10.6-4 ii libsecret-1-0 0.20.5-3 ii libsoup-3.0-0 3.2.2-2 ii libsqlite3-0 3.40.1-2 ii libwebkit2gtk-4.1-0 2.40.0-3 ii libxml2 2.9.14+dfsg-1.2 Versions of packages epiphany-browser recommends: ii ca-certificates 20230311 ii evince 43.1-2+b1 ii yelp 42.2-1 epiphany-browser suggests no packages. -- no debconf information -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#891685: castle-game-engine: FTBFS on m68k: color and vector tests fail
Hi, On Thu, 2022-05-26 at 20:23 +0200, Abou Al Montacir wrote: > CGE build correctly on m68k architecture now. This was broken again in new upstream 7.0~alpha.2 release. There was a rework of TVector3Byte where the base data was changed from an array to a record fields and a default property was added to allow array like access. However, this array like property is read only, while a load from stream function tries, in big endian mode, to switch bytes. While I don't think this swap endianess code is needed at all, I would preferred a faster implementation with basic records: TVector3Byte = packed record case Boolean of: false: (x, y, z: Byte); true: (AsBytes: array[0..2] of Byte); end; Anyway, I'll let upstream fix this as they wants, but probably this will never be in Bookworms. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1033901: Acknowledgement (unblock: castle-game-engine/7.0~alpha.2+dfsg1-4)
Control: retitle -1 unblock: castle-game-engine/7.0~alpha.2+dfsg1-5
On Mon, 2023-04-03 at 20:22 +0200, Abou Al Montacir wrote:
> This ticket should be seen as an add
> on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033840 which was
> accepted.
Unfortunately, I forgot to add the patch of 7.0~alpha.2+dfsg1-3 to the series
file.So the patch was not applied.
Also the rm line was done after the package was built.
This time I verified that the files inside the .deb are really patched and those
to be removed were really missing. Sorry for inconvenience.
PS: debdiff against 7.0~alpha.2+dfsg1-4
--
Cheers,
Abou Al Montacir
diff -Nru castle-game-engine-7.0~alpha.2+dfsg1/debian/changelog castle-game-engine-7.0~alpha.2+dfsg1/debian/changelog
--- castle-game-engine-7.0~alpha.2+dfsg1/debian/changelog 2023-04-03 15:07:29.0 +0200
+++ castle-game-engine-7.0~alpha.2+dfsg1/debian/changelog 2023-04-04 11:08:10.0 +0200
@@ -1,3 +1,10 @@
+castle-game-engine (7.0~alpha.2+dfsg1-5) unstable; urgency=medium
+
+ * Applied patch to use local jquery version instead of web based one.
+ * Remove statically linked libraries and object files from source package.
+
+ -- Abou Al Montacir Tue, 04 Apr 2023 11:08:10 +0200
+
castle-game-engine (7.0~alpha.2+dfsg1-4) unstable; urgency=medium
* Fixed compilation on mipsel.
diff -Nru castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/series castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/series
--- castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/series 2023-04-03 08:43:08.0 +0200
+++ castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/series 2023-04-04 09:40:52.0 +0200
@@ -8,3 +8,4 @@
Fix-UTF-8-BOM.patch
f0fe0583dded3d0c27ae46fde59a00f58a777e46.patch
Fixed-compilation-on-mipsel.patch
+Replaced-web-baseed-jquery-by-local-version.patch
diff -Nru castle-game-engine-7.0~alpha.2+dfsg1/debian/rules castle-game-engine-7.0~alpha.2+dfsg1/debian/rules
--- castle-game-engine-7.0~alpha.2+dfsg1/debian/rules 2023-04-02 16:37:28.0 +0200
+++ castle-game-engine-7.0~alpha.2+dfsg1/debian/rules 2023-04-04 11:06:47.0 +0200
@@ -105,7 +105,11 @@
${MKDIR} ${SRC_DIR}
${CP} -t ${SRC_DIR} \
$(CURDIR)/src/*
+ # Remove statically linked libraries and object files from source packages
+ find ${SRC_DIR} -name '*.a' -o -name '*.o' -o -name '*.obj' -delete
+ # Fix files permission
find $(SRC_DIR) -name '*.bmp' -o -name '*.pas' -exec chmod 644 '{}' ';'
+ # Remove empty directories
find ${SRC_DIR} -empty -delete
touch install-source-stamp
@@ -142,9 +146,6 @@
${RM} doc/reference/tipuesearch/jquery.min.js
# Remove .npmignore file as Lintian complains about it.
${RM} doc/reference/castle-engine-website-base/node_modules/slick-carousel/.npmignore
- # Remove statically linked libraries from source packages as Lintian
- # complains about it.
- ${RM} src/vampyre_imaginglib/src/Extensions/*/*.a
# Remove windows executable files as Lintian complains about them.
${RM} tools/contrib/x86_64-win64
signature.asc
Description: This is a digitally signed message part
Bug#1033901: Acknowledgement (unblock: castle-game-engine/7.0~alpha.2+dfsg1-4)
This ticket should be seen as an add on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033840 which was accepted. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1033901: unblock: castle-game-engine/7.0~alpha.2+dfsg1-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package castle-game-engine
[ Reason ]
Fix compilation on mipsel architecture (Closes: Bug#891683)
[ Impact ]
No impact on other architectures. Fixes the compilation on mipsel.
[ Tests ]
The test suite was running on other architectures and will run on mipsel.
[ Risks ]
Probably none.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
This will allow to bring mipsel to the supported architectures while not
impacting at all any other architecture.
The changes are just fixing compilation directives that are specific to mips
and mipsel.
unblock castle-game-engine/7.0~alpha.2+dfsg1-4
diff -Nru castle-game-engine-7.0~alpha.2+dfsg1/debian/changelog
castle-game-engine-7.0~alpha.2+dfsg1/debian/changelog
--- castle-game-engine-7.0~alpha.2+dfsg1/debian/changelog 2023-04-02
16:44:18.0 +0200
+++ castle-game-engine-7.0~alpha.2+dfsg1/debian/changelog 2023-04-03
15:07:29.0 +0200
@@ -1,3 +1,11 @@
+castle-game-engine (7.0~alpha.2+dfsg1-4) unstable; urgency=medium
+
+ * Fixed compilation on mipsel.
+On mipsel both CPUmips and CPUmipsel are defined by the compiler.
+(Closes: Bug#891683)
+
+ -- Abou Al Montacir Mon, 03 Apr 2023 15:07:29 +0200
+
castle-game-engine (7.0~alpha.2+dfsg1-3) unstable; urgency=medium
* Removed unused binary files to fix lintian reported errors.
diff -Nru
castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/Fixed-compilation-on-mipsel.patch
castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/Fixed-compilation-on-mipsel.patch
---
castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/Fixed-compilation-on-mipsel.patch
1970-01-01 01:00:00.0 +0100
+++
castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/Fixed-compilation-on-mipsel.patch
2023-04-03 15:04:37.0 +0200
@@ -0,0 +1,22 @@
+Description: Fixed compilation on mipsel
+ This patch fixes a bug causing CGE not compile on mipsel architecture.
+ .
+ The issue was that on mipsel both CPUmips and CPUmipsel are defined by the
+ compiler.
+Author: Abou Al Montacir
+
+diff --git a/tools/common-code/toolarchitectures.pas
b/tools/common-code/toolarchitectures.pas
+index 905fa46..9ae4e07 100644
+--- a/tools/common-code/toolarchitectures.pas
b/tools/common-code/toolarchitectures.pas
+@@ -138,8 +138,8 @@ const
+ {$ifdef CPUpowerpc64} powerpc64 {$endif}
+ {$ifdef CPUavr} avr {$endif}
+ {$ifdef CPUarmeb} armeb {$endif}
+-{$ifdef CPUmips} mips {$endif}
+-{$ifdef CPUmipsel} mipsel {$endif}
++{$ifdef CPUmipsel} mipsel {$else}
++{$ifdef CPUmips} mips {$endif}{$endif}
+ {$ifdef CPUjvm} jvm {$endif}
+ {$ifdef CPUi8086} i8086 {$endif}
+ {$ifdef CPUsparc64} sparc64 {$endif}
diff -Nru castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/series
castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/series
--- castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/series 2022-10-24
20:06:20.0 +0200
+++ castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/series 2023-04-03
08:43:08.0 +0200
@@ -7,3 +7,4 @@
77c97ef135eb5ad95c05d90edae11fa3d2863359.patch
Fix-UTF-8-BOM.patch
f0fe0583dded3d0c27ae46fde59a00f58a777e46.patch
+Fixed-compilation-on-mipsel.patch
Bug#1033840: unblock: castle-game-engine/7.0~alpha.2+dfsg1-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package castle-game-engine
[ Reason ]
Many lintian errors which can be fixed without any risk of regressions.
[ Impact ]
There should not be any impact. Only unused files are removed and using Debian
packaged jquery instead of a web based version.
[ Tests ]
Tested documentation to ensure that Debian packaged jquery works as the web
based version it replaced.
[ Risks ]
Documentation browsing may be not optimal, but unlikely.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
The changes are not intrusive and should help having a cleaner package for
Bookworm with less lintian detected errors, while almost no risk.
unblock castle-game-engine/7.0~alpha.2+dfsg1-3
diff -Nru castle-game-engine-7.0~alpha.2+dfsg1/debian/changelog
castle-game-engine-7.0~alpha.2+dfsg1/debian/changelog
--- castle-game-engine-7.0~alpha.2+dfsg1/debian/changelog 2022-10-24
20:19:14.0 +0200
+++ castle-game-engine-7.0~alpha.2+dfsg1/debian/changelog 2023-04-02
16:44:18.0 +0200
@@ -1,3 +1,15 @@
+castle-game-engine (7.0~alpha.2+dfsg1-3) unstable; urgency=medium
+
+ * Removed unused binary files to fix lintian reported errors.
+Removed files are either unused statically liked libraries or some
+supplied windows programs or npm ignore file.
+These files were included in the source packages, but are not useful for
+Debian users.
+ * Replaced use of web based jquery.js with debian packaged version.
+Added dependency on libjs-jquery dor documentation package.
+
+ -- Abou Al Montacir Sun, 02 Apr 2023 16:44:18 +0200
+
castle-game-engine (7.0~alpha.2+dfsg1-2) unstable; urgency=medium
* Fixed build issue on arm64 and ppc64el.
diff -Nru castle-game-engine-7.0~alpha.2+dfsg1/debian/control
castle-game-engine-7.0~alpha.2+dfsg1/debian/control
--- castle-game-engine-7.0~alpha.2+dfsg1/debian/control 2022-09-18
21:58:19.0 +0200
+++ castle-game-engine-7.0~alpha.2+dfsg1/debian/control 2023-04-02
16:15:36.0 +0200
@@ -76,11 +76,11 @@
${misc:Depends},
fonts-droid-fallback,
fonts-dejavu-core,
+ libjs-bootstrap,
+ libjs-jquery,
Suggests:
castle-game-engine-src,
fp-units-castle-game-engine,
- libjs-bootstrap,
- libjs-jquery,
Multi-Arch: foreign
Description: Castle Game Engine - Developer's Documentation
Castle Game Engine is a set of LGPL licenced libraries that are intended to
diff -Nru
castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/Replaced-web-baseed-jquery-by-local-version.patch
castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/Replaced-web-baseed-jquery-by-local-version.patch
---
castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/Replaced-web-baseed-jquery-by-local-version.patch
1970-01-01 01:00:00.0 +0100
+++
castle-game-engine-7.0~alpha.2+dfsg1/debian/patches/Replaced-web-baseed-jquery-by-local-version.patch
2023-04-02 16:11:17.0 +0200
@@ -0,0 +1,70 @@
+Description: Replaced web baseed jquery by local version
+ Lintian doesn't like to use web based jquery.
+ We use locally installed verision from libjs-jquery.
+Author: Abou Al Montacir
+
+diff --git
a/doc/pasdoc/html-parts/castle-engine-website-base/node_modules/jquery-colorbox/example1/index.html
b/doc/pasdoc/html-parts/castle-engine-website-base/node_modules/jquery-colorbox/example1/index.html
+index 8f10b93..98bca68 100644
+---
a/doc/pasdoc/html-parts/castle-engine-website-base/node_modules/jquery-colorbox/example1/index.html
b/doc/pasdoc/html-parts/castle-engine-website-base/node_modules/jquery-colorbox/example1/index.html
+@@ -9,7 +9,7 @@
+ h2{font-size:13px; margin:15px 0 0 0;}
+
+
+- https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"</a>;>
++
+
+
+ $(document).ready(function(){
+diff --git
a/doc/pasdoc/html-parts/castle-engine-website-base/node_modules/jquery-colorbox/example2/index.html
b/doc/pasdoc/html-parts/castle-engine-website-base/node_modules/jquery-colorbox/example2/index.html
+index 8f10b93..98bca68 100644
+---
a/doc/pasdoc/html-parts/castle-engine-website-base/node_modules/jquery-colorbox/example2/index.html
b/doc/pasdoc/html-parts/castle-engine-website-base/node_modules/jquery-colorbox/example2/index.html
+@@ -9,7 +9,7 @@
+ h2{font-size:13px; margin:15px 0 0 0;}
+ </style>
+ <link rel="stylesheet" href="colorbox.css" />
+- <script
src="<a rel="nofollow" href="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js&q
Bug#1033798: unblock: lazarus/2.2.6+dfsg1-1
Control: retitle -1 unblock: lazarus/2.2.6+dfsg1-2
Another bug was fixed in order to allow building Lazarus for armel architecture.
This bug is just disabling a compilation switch in a source file.
The removed compilation switch forces to disable the FPU emulation, which does
not have any sense on armel as it does not have any hardware FPU.
The fix should not alter other architectures as when the switch is not supplied,
FPC will decide automatically whether to use HW FPU of emulation.
Attached the debdiff of this altest modification.
--
Cheers,
Abou Al Montacir
diff -Nru lazarus-2.2.6+dfsg1/debian/changelog lazarus-2.2.6+dfsg1/debian/changelog
--- lazarus-2.2.6+dfsg1/debian/changelog 2023-03-31 19:51:15.0 +0200
+++ lazarus-2.2.6+dfsg1/debian/changelog 2023-04-01 19:28:43.0 +0200
@@ -1,3 +1,9 @@
+lazarus (2.2.6+dfsg1-2) unstable; urgency=medium
+
+ * Fixed compilation of test suite on armel.
+
+ -- Abou Al Montacir Sat, 01 Apr 2023 19:28:43 +0200
+
lazarus (2.2.6+dfsg1-1) unstable; urgency=medium
* New upstream version 2.2.6+dfsg1
diff -Nru lazarus-2.2.6+dfsg1/debian/patches/Fixed-compilation-of-testsuite-on-armel.patch lazarus-2.2.6+dfsg1/debian/patches/Fixed-compilation-of-testsuite-on-armel.patch
--- lazarus-2.2.6+dfsg1/debian/patches/Fixed-compilation-of-testsuite-on-armel.patch 1970-01-01 01:00:00.0 +0100
+++ lazarus-2.2.6+dfsg1/debian/patches/Fixed-compilation-of-testsuite-on-armel.patch 2023-04-01 19:26:12.0 +0200
@@ -0,0 +1,23 @@
+Description: Fixed compilation of test suite on armel.
+ The crash was due to a source file disabling FPU emulation.
+ However, on armel, FPU emulation is needed as no hardware FPU
+ is present.
+ .
+ This patch removed the compiler flag that disabled the FPU emulation.
+ This should not harm, as on other targets, the compiler will by default use
+ the hardware FPU.
+Author: Abou Al Montacir
+
+diff --git a/components/lazreport/source/addons/addfunction/frFuncNum.pas b/components/lazreport/source/addons/addfunction/frFuncNum.pas
+index 769a340d..75e9c037 100644
+--- a/components/lazreport/source/addons/addfunction/frFuncNum.pas
b/components/lazreport/source/addons/addfunction/frFuncNum.pas
+@@ -10,7 +10,7 @@ unit frFuncNum;
+
+ interface
+
+-{$A+,B-,E-,R-}
++{$A+,B-,R-}
+ {.$I FR.inc}
+
+ uses
diff -Nru lazarus-2.2.6+dfsg1/debian/patches/series lazarus-2.2.6+dfsg1/debian/patches/series
--- lazarus-2.2.6+dfsg1/debian/patches/series 2023-03-31 19:51:08.0 +0200
+++ lazarus-2.2.6+dfsg1/debian/patches/series 2023-04-01 19:26:12.0 +0200
@@ -8,3 +8,4 @@
Fixed-end-of-line-for-resource-file.diff
Fixed-allowing-arbitrary-FPPKG-path.patch
Added-missing-source-file.patch
+Fixed-compilation-of-testsuite-on-armel.patch
diff -Nru lazarus-2.2.6+dfsg1/debian/source/timestamps lazarus-2.2.6+dfsg1/debian/source/timestamps
--- lazarus-2.2.6+dfsg1/debian/source/timestamps 2023-03-25 15:09:07.0 +0100
+++ lazarus-2.2.6+dfsg1/debian/source/timestamps 2023-04-01 19:28:07.0 +0200
@@ -1,5 +1,6 @@
components/PascalScript/Source/arm.inc 2020-08-08T09:46+00:00
components/PascalScript/Source/pascalscriptfcl.pas 2022-01-28T09:54+00:00
+components/lazreport/source/addons/addfunction/frFuncNum.pas 2023-04-01T17:28+00:00
ide/codehelp.pas 2020-07-11T19:46+00:00
ide/generatefppkgconfigurationdlg.pas 2022-01-16T13:55+00:00
lcl/include/lcl_defines.inc 2020-07-11T19:46+00:00
signature.asc
Description: This is a digitally signed message part
Bug#1033798: unblock: lazarus/2.2.6+dfsg1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package lazarus Lazarus is an IDE and a library for rapid application development using Free Pascal Compiler. [ Reason ] New upstream maintenance release. [ Impact ] Several bugs were reported by users to upstream are fixed in this new release. This is a maintenance release only, so no new feature was added, only fixed bugs. [ Tests ] Upstream added tests to the test suite for several fixed bugs. Lazarus have a big test suite that aims to catch most regressions. [ Risks ] Risk is moderated as this is a bug fixes only. It was release by upstream 9th of March and users seems to be happy. The new release was packaged to unstable, and current Debian SW using Lazarus to build seems rebuildign correctly with the new release. [ Checklist ] [ ] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] Thaking into account the long Debian release cycle, it is probably good to include this maintenance release in order to avoid packaging a version we know already that it has several bugs. Also taking into accoutn the small number of users of Lazarus on Debian, I don't want to loose any of them because we carry an outdated version (most users complain is that Debian always carries outdated versions with bugs that are already fixed in newer upstream versions). unblock lazarus/2.2.6+dfsg1-1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 3.0 (quilt) Source: lazarus Binary: lazarus-2.2, lazarus-src-2.2, lazarus-ide-2.2, lazarus-ide-gtk2-2.2, lazarus-ide-qt5-2.2, lcl-2.2, lcl-utils-2.2, lcl-units-2.2, lcl-nogui-2.2, lcl-gtk2-2.2, lcl-qt5-2.2, lazarus-doc-2.2, lazarus, lazarus-src, lazarus-ide, lazarus-ide-gtk2, lazarus-ide-qt5, lcl, lcl-utils, lcl-units, lcl-nogui, lcl-gtk2, lcl-qt5, lazarus-doc Architecture: any all Version: 2.2.4+dfsg1-3 Maintainer: Pascal Packaging Team Uploaders: Abou Al Montacir , Paul Gevers Homepage: https://www.lazarus-ide.org/ Standards-Version: 4.4.1 Vcs-Browser: https://salsa.debian.org/pascal-team/lazarus Vcs-Git: https://salsa.debian.org/pascal-team/lazarus.git Testsuite: autopkgtest Testsuite-Triggers: @builddeps@ Build-Depends: debhelper (>= 11~), fp-utils (>= 3.2.0~), fpc (>= 3.2.0~), fpc-source (>= 3.2.0~), libgtk2.0-dev, libqt5pas-dev (>= 2.6~beta-6~), po-debconf, rdfind, symlinks Package-List: lazarus deb devel optional arch=all lazarus-2.2 deb devel optional arch=all lazarus-doc deb doc optional arch=all lazarus-doc-2.2 deb doc optional arch=all lazarus-ide deb devel optional arch=all lazarus-ide-2.2 deb devel optional arch=any lazarus-ide-gtk2 deb devel optional arch=all lazarus-ide-gtk2-2.2 deb devel optional arch=any lazarus-ide-qt5 deb devel optional arch=all lazarus-ide-qt5-2.2 deb devel optional arch=any lazarus-src deb devel optional arch=all lazarus-src-2.2 deb devel optional arch=all lcl deb devel optional arch=all lcl-2.2 deb devel optional arch=any lcl-gtk2 deb devel optional arch=all lcl-gtk2-2.2 deb devel optional arch=any lcl-nogui deb devel optional arch=all lcl-nogui-2.2 deb devel optional arch=any lcl-qt5 deb devel optional arch=all lcl-qt5-2.2 deb devel optional arch=any lcl-units deb devel optional arch=all lcl-units-2.2 deb devel optional arch=any lcl-utils deb devel optional arch=all lcl-utils-2.2 deb devel optional arch=any Checksums-Sha1: 988d4db6652862c358a6222ab603d4a7e629deba 54668272 lazarus_2.2.4+dfsg1.orig.tar.xz 78e6400b5dad246e7d9bc5b44d448e3a79de3b70 68204 lazarus_2.2.4+dfsg1-3.debian.tar.xz Checksums-Sha256: e649e69657d5e3038da5efc0123d08bfd410f30d414e4cc787a92d0453ad2877 54668272 lazarus_2.2.4+dfsg1.orig.tar.xz 27767146278cf967a02be0df004df6aa68151179d60ea49f8c3a8095dbf9655d 68204 lazarus_2.2.4+dfsg1-3.debian.tar.xz Files: b1ac009c2b8ac2fd5cdf10db66ec7f39 54668272 lazarus_2.2.4+dfsg1.orig.tar.xz 979ef81a90b43fcda252b2d0d925bdb5 68204 lazarus_2.2.4+dfsg1-3.debian.tar.xz -BEGIN PGP SIGNATURE- iI0EAREKADUWIQS69sZENhB4UNQicQazJVxtVYeNjAUCZB7cDRccYWJvdS5hbG1v bnRhY2lyQHNmci5mcgAKCRCzJVxtVYeNjA35AP9ois9EsD3ShcZJr2LnwSmEhaV3 AhKCcHutK6WhVQgoKwEAhSlNmjXYYCcjw2upux9IcmlfCqvMgoOAWqNCU5hC9pg= =wp53 -END PGP SIGNATURE- -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 3.0 (quilt) Source: lazarus Binary: lazarus-2.2, lazarus-src-2.2, lazarus-ide-2.2, lazarus-ide-gtk2-2.2, lazarus-ide-qt5-2.2, lcl-2.2, lcl-utils-2.2, lcl-units-2.2, lcl-nogui-2.2, lcl-gtk2-2.2, lcl-qt5-2.2, lazarus-doc-2.2, lazarus, lazarus-src, lazarus-ide, lazarus-ide-gtk2, lazarus-ide-qt5, lcl, lcl-utils, lcl-units, lcl-nogui, lcl-gtk2, lcl-qt5, lazarus-doc Architecture: any all Version: 2.2.6+dfsg1-1 Maintainer: Pascal Packaging Team Uploaders: Abou Al Montacir , Paul Gevers Homepage: https://www.lazarus-ide.org/ Standards-Version: 4.4.1 Vcs-Browser: https://s
Bug#1033763: unblock: fpc/3.2.2+dfsg-20
Hi, On Sat, 2023-04-01 at 02:20 +0200, Abou Al Montacir wrote: > ... > [x] attach debdiff against the package in testing > ... Attaching debdiff -- Cheers, Abou Al Montacir diff -Nru fpc-3.2.2+dfsg/debian/changelog fpc-3.2.2+dfsg/debian/changelog --- fpc-3.2.2+dfsg/debian/changelog 2023-03-17 13:45:28.0 +0100 +++ fpc-3.2.2+dfsg/debian/changelog 2023-03-30 21:31:30.0 +0200 @@ -1,3 +1,10 @@ +fpc (3.2.2+dfsg-20) unstable; urgency=medium + + * Fixed compiler internal error 2003042401 on mipsel. +This error occurs when compiling Lazarus on mipsel architecture. + + -- Abou Al Montacir Thu, 30 Mar 2023 21:31:30 +0200 + fpc (3.2.2+dfsg-19) unstable; urgency=medium * Fixed missing crtbeginS.o on mipsel architecture. diff -Nru fpc-3.2.2+dfsg/debian/patches/5-85c7368759f5fb53aa23e03c8cc27c2deb424b62.patch fpc-3.2.2+dfsg/debian/patches/5-85c7368759f5fb53aa23e03c8cc27c2deb424b62.patch --- fpc-3.2.2+dfsg/debian/patches/5-85c7368759f5fb53aa23e03c8cc27c2deb424b62.patch 1970-01-01 01:00:00.0 +0100 +++ fpc-3.2.2+dfsg/debian/patches/5-85c7368759f5fb53aa23e03c8cc27c2deb424b62.patch 2023-03-29 13:43:22.0 +0200 @@ -0,0 +1,24 @@ +From 85c7368759f5fb53aa23e03c8cc27c2deb424b62 Mon Sep 17 00:00:00 2001 +From: florian +Date: Wed, 24 Aug 2022 21:15:18 +0200 +Subject: [PATCH] * handle also simulated flags in + tmipselnotnode.second_boolean, resolves #39877 + +--- + compiler/mips/ncpumat.pas | 31 --- + tests/webtbs/tw39877.pp | 15 +++ + 2 files changed, 31 insertions(+), 15 deletions(-) + create mode 100644 tests/webtbs/tw39877.pp + +diff --git a/fpcsrc/compiler/mips/ncpumat.pas b/fpcsrc/compiler/mips/ncpumat.pas +index 9db7c052..5b33a866 100644 +--- a/fpcsrc/compiler/mips/ncpumat.pas b/fpcsrc/compiler/mips/ncpumat.pas +@@ -245,6 +245,7 @@ begin + begin + secondpass(left); + case left.location.loc of ++ LOC_FLAGS, + LOC_REGISTER, LOC_CREGISTER, LOC_REFERENCE, LOC_CREFERENCE, + LOC_SUBSETREG,LOC_CSUBSETREG,LOC_SUBSETREF,LOC_CSUBSETREF: + begin diff -Nru fpc-3.2.2+dfsg/debian/patches/series fpc-3.2.2+dfsg/debian/patches/series --- fpc-3.2.2+dfsg/debian/patches/series 2023-03-15 14:20:00.0 +0100 +++ fpc-3.2.2+dfsg/debian/patches/series 2023-03-29 13:09:50.0 +0200 @@ -34,3 +34,4 @@ pas2jni-cthreads.patch change_fpmake_to_install_missing_package_examples.patch Fix-missing-crtbeginS.o-on-mipsel.patch +5-85c7368759f5fb53aa23e03c8cc27c2deb424b62.patch diff -Nru fpc-3.2.2+dfsg/debian/source/timestamps fpc-3.2.2+dfsg/debian/source/timestamps --- fpc-3.2.2+dfsg/debian/source/timestamps 2023-03-15 14:20:00.0 +0100 +++ fpc-3.2.2+dfsg/debian/source/timestamps 2023-03-29 13:45:08.0 +0200 @@ -5,6 +5,7 @@ fpcsrc/compiler/globals.pas 2020-05-14T13:54+00:00 fpcsrc/compiler/hlcgobj.pas 2020-05-14T13:54+00:00 fpcsrc/compiler/m68k/cpubase.pas 2022-05-26T16:24+00:00 +fpcsrc/compiler/mips/ncpumat.pas 2023-03-29T11:45+00:00 fpcsrc/compiler/ncgvmt.pas 2022-11-19T17:36+00:00 fpcsrc/compiler/powerpc64/cgcpu.pas 2022-11-19T17:36+00:00 fpcsrc/compiler/powerpc64/cpupara.pas 2022-05-26T16:24+00:00 signature.asc Description: This is a digitally signed message part
Bug#1033763: unblock: fpc/3.2.2+dfsg-20
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package fpc Fixed compiler crash by applying a patch from upstream. [ Reason ] When compiling some packages on mipsel, FPC craches with internal error 2003042401. This issue was solved by upstream. [ Impact ] The fix is in a file specific to the mipsel code generator, so can not impact any other architecutre. It adds code generation for a special combination of opcode and operands. The same code exists already for similar architectures like SPARC. [ Tests ] The code file producing the internal error is now compiled correctly. There is a test produced by upstream to test this fix, but we decided not to include it in order not to increase the size of the patch. [ Risks ] No risks are foreseen. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] This patch was produced by FPC upstream mipsel maintainer and was included for long time in their daily snapshots.
Bug#997948: FPC should provide a way to trigger automatic rebuild of
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? -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#825222: lintian: please allow debian/source/timestamps in unknown-file-in-debian-source
Hi Alex, On Sun, 15 Jan 2023 20:21:49 +0100 Axel Beckert wrote: > Control: tag -1 wontfix > > Hi, > > Abou Al Montacir wrote: > > I recently was interested in solving Lintian errors on FPC and > > friends and got pointed to this ticket. > > I just checked > https://codesearch.debian.net/search?q=2022+path%3Adebian%2Fsource%2Ftimestamps; literal=1 > and it seems that exactly 2 source packages (fpc and lazarus) are using this. Yes indeed, only tow packages for now are using this file, but theoretically any package built by FPC may need this. > > Just affecting two packages is IMHO a valid case for lintian > overrides. I may agree, but I failed to find the right syntax to override this error. There seem also 9 packages they do the same according to https://lintian.debian.org/tags/unknown-file-in-debian-source So are you sur the override is working, and if yes, how to do it. We tried https://sources.debian.org/src/fpc/3.2.2%2Bdfsg- 18/debian/source/lintian-overrides/ but also several other syntaxes and it fails. It seems no package managed to override it as far as I can search. > > It's though a small change with practically no chance for false > positives, so I'm no directly opposed to implementing it. > > I though wonder: Are more packages expected to use that? I mean, the > initial bug report ist from 2016 and I only see two packages using it. > > > I tend to agree with Paul that the timestamps file is better located in > > debian/source folder and would lobby for that. > > This seems to be the wrong audience for a discussion about the > location of that file. Such a discussion should come _before_ Lintian is > asked to implement something. I do Agree here about what you said, but we should just know how to override it, if ever possible. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1016562: [Pkg-pascal-devel] Bug#1016562: Bug#1016562: fp-compiler-3.2.0: Fails to setup during install due to "Invalid floating point operation"
Hi William On Sun, 2022-12-18 at 16:12 +0100, William Di Luigi wrote: > Hello, it's easy to reproduce this using Docker, no need for VMWare or qemu or > any VM for that matter. > > I am using Docker (from a M1 macbook) I trust it is as easy as that if you have the right HW, but I don't. I need to setup a VM to debug that. However as the issue does not affect Bookworm, I'd say I'll just upload latest FPC version to backports, and will not bother to debug this. It is probably a bug in code generator and this will be very hard to find at Debian level, while upstream will not like to debug an old version. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1026718: [Pkg-pascal-devel] Bug#1026719: preventing lazpaint package removal
control: forcemerge 1026719 -1 -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1026718: [Pkg-pascal-devel] Bug#1026719: preventing lazpaint package removal
control: reassign -1 fpc control: forcemerge -1 1026718 On Sat, 2023-01-07 at 15:31 +, Peter B wrote: > I notice the fpc upload is closing 1026719, but not 1026718. > > Maybe 1026718 needs closing manually? I'm merging them. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#825222: lintian: please allow debian/source/timestamps in unknown-file-in-debian-source
Control: reopen -1 Hi Dear Lintian maintainer, I recently was interested in solving Lintian errors on FPC and friends and got pointed to this ticket. I tend to agree with Paul that the timestamps file is better located in debian/source folder and would lobby for that. Can you please reassess this request? -- 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 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: [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
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#967348: fpc: depends on deprecated GTK 2
Control: forwarded - 1 https://gitlab.com/freepascal.org/fpc/source/-/issues/39989 Created upstream ticket on https://gitlab.com/freepascal.org/fpc/source/-/issues/39989 -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1016562: [Pkg-pascal-devel] Bug#1016562: fp-compiler-3.2.0: Fails to setup during install due to "Invalid floating point operation"
Hi Graham, > I was trying to install the Free Pascal Compiler on Debian 11 running under > VMware Fusion on an Mac > with an M2 processor. Can you please tell if you can reproduce using qemu or at least provide instruction ho to run VMware for that purpose? Can you confirm this is an ARM Cortex-M2 processor? Do that have an FPU? -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1022343: [Pkg-pascal-devel] Bug#1022343: Bug#1022343: view3dscene: FTBFS: view3dscene.lpr(63, 17) Fatal: Can't find unit CastleCubeMaps used by view3dscene
On Mon, 2022-10-24 at 01:34 +0200, Michalis Kamburelis wrote: > So my preferred way to solve this would be to just have view3dscene > 4.2.0 in Debian. Yes, I'm working on it! -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#748789: fpc view3dscene bug: document why tagging this bug as wontfix
tag -1 wontfix As per upstream closure of the ticket on their bug tracker, this issue won't be fixed and they recommend to user -Ur switch. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#891685: [Pkg-pascal-devel] Bug#891685: castle-game-engine: FTBFS on m68k: color and vector tests fail
Fixed -1 7.0~alpha.1+dfsg-8 CGE build correctly on m68k architecture now. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#891683: [Pkg-pascal-devel] Bug#891683: castle-game-engine: FTBFS on mips(el): Cannot load FreeType library
CGE still fails building for mips based architectures. We think there is an issue in FPC, so waiting it get fixed in the next compiler release. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1011318: [Pkg-pascal-devel] Bug#1011318: Bug#1011318: fp terminal ide does not compile hello world
We got answer from upstream that explains the issue. The IDE does not use /etc/fpc.cfg but /etc/fp.cfg which is not created by Debian package. > > Can anyone using fp IDE check the following issue or at least let us > > know if it happens on stock FPC distributed binaries. > > The IDE does not use fpc.cfg, but fp.cfg. The default installer script > creates such a file in lib/fpc/$fpcversion/ide/text with appropriate > search paths for the default units. The ide can find it there. > > Note: if there is an existing existing fp.cfg in the current directory, > that will override the default one. This will probably be the case if > the IDE has been started before without it being able to find an > existing fp.cfg, because then it will ask to create one in the current > directory. So even if the package gets fixed, people may still have > problems afterwards if they don't delete local fp.cfg files (the same > goes for fp.dsk and fp.ini, but those are less likely to cause issues if > they're not based on the default ones). -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1011318: [Pkg-pascal-devel] Bug#1011318: fp terminal ide does not compile hello world
Hi Steve, Thank you reporting this issue. On Fri, 2022-05-20 at 01:02 +, Steve Greenburg wrote: > ... > (1,1) Fatal: Can't find unit system used by > Program ▲ > (0) Fatal: Compilation aborted Yes I can reproduce. > ... > The config file is /etc/fpc.cfg and it mentions the above path but with > symbols. For example it has '$fpcversion' instead of '3.2.2'. Strangely the > 'fpc' compiler itself uses this file but has no problems. I have tested this > on latest debian testing. I'm not sure how to fix the problem in fp itself > however other than through the GUI or why it's not using the fpc.cfg file > properly. Using the following path in the GUI works also: /usr/lib/x86_64-linux-gnu/fpc/$fpcversion/units/x86_64-linux/* So the issue seems more that the IDE does not parse /etc/fpc.cfg rather than not expanding the configuration variables. Not sure if this is Debian specific or is also the case of upstream binaries. I'll check with upstream. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1004982: lazarus-src-2.2: Unable to remove the package under ru_RU.UTF-8 locale
Hi Alexander,
Thank you reporting this issue.
> Note that "diversion of" is translated as "отклонение", with different amount
> of spaces. So, postrm script uses wrong field as a filename.
The script should enforce LANG=C when running such a command. I'll try to
prepare a patch for that.
Can you please check that hte following commands work correctly?
DIVERTIONS_LIST=`LANG=C dpkg-divert --list "/usr/lib/lazarus/2.2.0/*" | cut -d
' ' -f 3`
echo ${DIVERTIONS_LIST}
If this is OK, please let me know so I can upload a fix.
--
Cheers,
Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
Bug#551400: fpc on kfreebsd-i386
Hi All, On Sun, 2017-10-01 at 12:30 +0200, Abou Al Montacir wrote: > > In fastcgi and fcl-web, something goes wrong with linking: > >ELF interpreter /usr/libexec/ld-elf.so.1 not found > > I have no idea where this comes from as all references to libexec are > > either in fpmake itself after compilation or in t_bsd.pas (which code I > > removed below anyway to be sure). > As far as I can see this seems to be part of binutils-2.25 but not in Debian. > http://nixdoc.net/man-pages/FreeBSD/ld-elf.so.1.1.html gives some explanation > about this: > The ld-elf.so.1 utility itself is loaded by the kernel together with any > dynamically-linked program that is to be executed. The kernel transfers > control to the dynamic linker. After the dynamic linker has finished > loading, relocating, and initializing the program and its required shared > objects, it transfers control to the entry point of the program. I looked a little bit more in this issue and understood it. The path /usr/libexec/ld-elf.so.1 is inserted by the ld-bfd itself. One simple way to fix it is to modify the build configuration file as follows: $ cat fpc-3.2.2+dfsg/debian/deb-build-fpc.cfg # FPC configuration file for build system tools -k-z relro -z now -I /lib/ld-kfreebsd-x86-64.so.1 -Fl/usr/lib/x86_64-kfreebsd-gnu So it looks like a bug in the port rather than in FPC itself. However, even after solving this, we have still other issues. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1002961: src:castle-game-engine: fails to migrate to testing for too long: FTBFS on armel
Hi Paul, On Mon, 2022-01-24 at 00:16 +0100, Abou Al Montacir wrote: > Hi Paul, > > On Sun, 2022-01-02 at 16:30 +0100, Paul Gevers wrote: > > .. > > Moreover CGE upstream think we should abandon armel (and other non > > widely used architectures) as a target for CGE, but I think myself it is > > a good test for the compiler and tend to think we should keep it. > > I agree with you. However, as a Release Team member, I also want to > prevent packages from being out-of-sync for too long. So, what I suggest > in this case is to temporarily disable the test on armel until we have > figured out how to fix the situation. That way the package can migrate > to testing, without making the situation much worse there. > Can you please review [1] before upload? > > [1] > https://salsa.debian.org/pascal-team/castle-game-engine/-/commit/d9b628c179bb53868e3d0bf9adc0b271969a613b Thanks for the review. I've uploaded with the tests moved to CI and the script executed as expected, but the CI system detects failure. I don't know why as I verified on my machine that the script returns 0 as exit code. It complains about messages on stderr, does it consider writing to stderr as a n error? In that case, is it possible to disable that? The test program is upstream maintained and I don't want to hack in it. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1002961: [Pkg-pascal-devel] Bug#1002961: Bug#1002961: src:castle-game-engine: fails to migrate to testing for too long: FTBFS on armel
Hi Paul, On Sun, 2022-01-02 at 16:30 +0100, Paul Gevers wrote: > > .. > > Moreover CGE upstream think we should abandon armel (and other non > > widely used architectures) as a target for CGE, but I think myself it is > > a good test for the compiler and tend to think we should keep it. > > I agree with you. However, as a Release Team member, I also want to > prevent packages from being out-of-sync for too long. So, what I suggest > in this case is to temporarily disable the test on armel until we have > figured out how to fix the situation. That way the package can migrate > to testing, without making the situation much worse there. Can you please review [1] before upload? [1] https://salsa.debian.org/pascal-team/castle-game-engine/-/commit/d9b628c179bb53868e3d0bf9adc0b271969a613b -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#902887: [Pkg-pascal-devel] Bug#902887: Bug#902887: Bug#902887: Bug#902887: -dbgsym not working
Control: forwarded -1 https://gitlab.com/freepascal.org/fpc/source/- /issues/39538 > Another question is, should we enforce this flag when building FPC itself, so > that one can debug the RTL, or do we consider this out of scope of FPC Debian > packages (means that who wants to debug RTL should build his own FPC!). It seems that upstream is now aware of this issue as it was raised by a user [1]. [1] https://gitlab.com/freepascal.org/fpc/source/-/issues/39538 -- Cheers, Abou Al Montacir ___ Pkg-pascal-devel mailing list pkg-pascal-de...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel signature.asc Description: This is a digitally signed message part
Bug#902887: [Pkg-pascal-devel] Bug#902887: Bug#902887: Bug#902887: -dbgsym not working
Control: forwarded - 1 https://gitlab.com/freepascal.org/fpc/source/-/issues/39538 > Another question is, should we enforce this flag when building FPC itself, so > that one can debug the RTL, or do we consider this out of scope of FPC Debian > packages (means that who wants to debug RTL should build his own FPC!). It seems that upstream is now aware of this issue as it was raised by a user [1]. [1] https://gitlab.com/freepascal.org/fpc/source/-/issues/39538 -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#902887: [Pkg-pascal-devel] Bug#902887: Bug#902887: Bug#902887: -dbgsym not working
Control: forwarded -1 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902887 > Another question is, should we enforce this flag when building FPC itself, so > that one can debug the RTL, or do we consider this out of scope of FPC Debian > packages (means that who wants to debug RTL should build his own FPC!). It seems that upstream is now aware of this issue as it was raised by a user [1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902887 -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1003895: [Pkg-pascal-devel] Bug#1003895: lazarus: undefined reference to QLCLOpenGLWidget
Hi Stephan, On Mon, 2022-01-17 at 20:50 +0100, Stephan Lachnit wrote: > ... > Dear maintainer, > > it looks like the update to 2.2.0 broke the Qt OpenGL Widget. I tried to > compile goverlay [1] with the new version, but it fails with the following > error message: There are more things broken unfortunately. I'm fixing them one by one and I hope I can fix them all soon. Help is welcome of course. > ... > > Maybe this is because libqtpas has not been updated for 2.2.0? This is possible. I'll upload a new qt5 soon. > If so, maybe it makes sense to rethink the decision of #922296 again to > prevent > this happening again in the future. I'll check this again to refresh my memory and we can talk about it. > > [1] https://salsa.debian.org/games-team/goverlay Nice tool, glad to see tools like that written with FPC+Lazarus. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#978040: [Pkg-pascal-devel] Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Hi Paul, On Sun, 2022-01-02 at 17:06 +0100, Paul Gevers wrote: > I'm not sure your allowed to run dpkg-reconfigure on a trigger as that > requires admin interaction. That sounds weird. As an admin I wouldn't > expect my configuration to get updated (when installing an "unrelated" > package). I just wanted to say that re-running dpkg-reconfigure did the trick. So we may be able to have a simpler script that regenerates the config file by running the required command and only that one. No need for a full reconfiguration, just un update of the path in /etc/fpc.cfg > And we would want to have a trigger on gcc upgrade? I don't > know how triggers work exactly, but wouldn't gcc need to provide the > trigger then? As far as I could see in [1], [2] and [3] we may be able to bypass gcc by triggering on /usr/lib/gcc or some of its sub folder. [1] https://wiki.debian.org/DpkgTriggers [2] https://stackoverflow.com/questions/15276535/dpkg-how-to-use-trigger [3] https://web.archive.org/web/20111022012105/http://www.seanius.net/blog/2009/09/dpkg-triggers-howto/ -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#1003627: [Pkg-pascal-devel] Bug#1003627: Bug#1003627: fpc: autopkgtest regression on ppc64el:
Hi, On Thu, 2022-01-13 at 19:39 +1100, David Bannon wrote: > > > I wonder if this relates to the hardening issue ? Hardening on PPC63le > with FPC is not currently working, it makes a non viable binary. > > https://gitlab.com/freepascal.org/fpc/source/-/issues/39451 The issue is due to the patch proposed by upstream and adding this test. I'll revert it. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#978040: [Pkg-pascal-devel] Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Hi Paul,
On Sun, 2022-01-02 at 08:19 +0100, Paul Gevers wrote:
> Hi,
>
> On 29-12-2021 23:47, Abou Al Montacir wrote:
> > So it should work correctly on all targets.
>
> Does this work correctly on all multiarch architectures too? I inspected
> only my own installation and there it only has cpui386 and cpux86_64.
If you check on a porter box for ARM or power PC, you will find only arm or ppc
related ifdefs.
So it works for all architectures, but not multiarch.
If we can safely suppose that all Debian architectures are using the very same
GCC version and path, then we can remove the ifdef and have a generic path that
works for mutiarch with a minimal effort.
>
> > However, it is true that if a new gcc version is installed after FPC
> > then the logic will fall down.
>
> Can't we use a wildcard for the version number? I mean, after 11 comes
> 12 and 13 and ...
The wildcards work but only for one directory level. This means /path/to/* and
/path/to/prefix* will work, but not /path/to/*/* or /path/to/prefix*/*
>
> > If this is judged OK, I propose to close this ticket
>
> As long as we have a new fpc in every Debian release, we're fine in
> Debian, but e.g. Ubuntu users may experience issues when they carry the
> same fpc over to a new version of Ubuntu that comes with a new gcc
> version. So I don't think it's nice.
If we can add a trigger then we can run dpkg-reconfigure fp-compiler-${VERSION}
and get it updated.
--
Cheers,
Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
Bug#1002961: [Pkg-pascal-devel] Bug#1002961: src:castle-game-engine: fails to migrate to testing for too long: FTBFS on armel
The issue is that there seem to be a bug in the compiler. However, I'm not able to understand what kind of issue and cloud not produce a small code that triggers it. Moreover, it seems that the bug itself is triggered only when running the full battery of tests. Then the failing test starts to fail. If the test is ran alone (after a machine reboot, or after a while) then it will succeed, but it one runs it after running the full test suite then it will fail systematically. No clue how to go forward and no enough information to open an upstream compiler bug. Moreover CGE upstream think we should abandon armel (and other non widely used architectures) as a target for CGE, but I think myself it is a good test for the compiler and tend to think we should keep it. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#997948: [Pkg-pascal-devel] Bug#997948: Bug#997948: Bug#997948: Reassign to fp-units-rtl
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. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#997948: [Pkg-pascal-devel] Bug#997948: Bug#997948: Reassign to fp-units-rtl
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. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#972536: [Pkg-pascal-devel] Bug#972536: fpc: the old version 3.0.4+dfsg-23 still in sid
Hi Xiao On Wed, 2020-10-21 at 10:28 +0800, xiao sheng wen wrote: > Perhaps the newer version of fpc upload to sid in next time, this old > version 3.0.4+dfsg-23 would automatically removed. > > Let us wait for some times. Can we close this ticket now that FPC-3.2.2 is in sid? -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#997947: [Pkg-pascal-devel] Bug#997947: Bug#997947: Bug#997947: Bug#997947: doublecmd FTBFS: Fatal: (10022) Can't find unit ExtCtrls used by uCmdBox
Control: merge -1 997948 After deeper analysis, I think, I finally found the issue: * doublecmd depends on lc-utils and pulls it. * lcl-utils depends on fp-compiler and pulls fp-compiler-3.2.2 * fp-compiler-3.2.2 pulls fp-units-rtl-3.2.0 * doublecmd depends on lc-units and pulls lcl-units-2.0 version 2.0.10 compiled with fpc 3.2.0 * lcl-units-2.0 pulls fp-units-rtl-3.2.0 which can coexist with fp-units-rtl- 3.2.0 therefore no error and both versions are installed. * doublecmd needs unit ExtCtrls which is compiled with fp-units-rtl-3.2.0 (installed) but the used compiler can only use system unit from fp-units-rtl- 3.2.2 thus the issue we see. Unfortunately, the only way to solve this is either to force using fp-compiler- 3.2.0 (non sense) or to force using a version of lcl-units-2.0 compiled with fp- compiler-3.2.2 (Bug#997948). Of course, even if Bug#997948 is solved, there will be always a time windows where doublecmd can be scheduled for build while Lazarus is not yet built. However this is a temporary situation that I won't solve. I advise, then, to close this ticket and let Bug#997948 open. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#978040: [Pkg-pascal-devel] Bug#978040: Bug#978040: Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
I have just checked on a new installation of FPC 3.2.2 on ARM and it looks like the detection of GCC library path is correct. # path to the gcclib #ifdef cpuaarch64 -Fl/usr/lib/gcc/arm-linux-gnueabi/11 #endif The code, internally uses; gcc --print-libgcc-file-name So it should work correctly on all targets. However, it is true that if a new gcc version is installed after FPC then the logic will fall down. If this is judged OK, I propose to close this ticket -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#997948: [Pkg-pascal-devel] Bug#997948: Reassign to fp-units-rtl
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? -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#997947: [Pkg-pascal-devel] Bug#997947: Bug#997947: Bug#997947: doublecmd FTBFS: Fatal: (10022) Can't find unit ExtCtrls used by uCmdBox
After checking the dependency of fp-units-gtk2-3.2.2, it looks really correct: # aptitude show fp-units-gtk2-3.2.2 Package: fp-units-gtk2-3.2.2 Version: 3.2.2+dfsg-1 New: yes State: installed Automatically installed: yes Multi-Arch: same Priority: optional Section: devel Maintainer: Pascal Packaging Team Architecture: amd64 Uncompressed Size: 9,008 k Depends: fp-units-fcl-3.2.2 (= 3.2.2+dfsg-1), fp-units-rtl-3.2.2 (= 3.2.2+dfsg-1), libgtk2.0-dev Breaks: fpc (<= 3.2.2+dfsg-0), fpc:i386 (<= 3.2.2+dfsg-0) Replaces: fpc (<= 3.2.2+dfsg-0), fpc:i386 (<= 3.2.2+dfsg-0) Provides: fp-units-gtk2 Description: Free Pascal - GTK+ 2.x units As you can seen the dependency between fp-units-gtk2-3.2.2 and fp-units-rtl- 3.2.2 are strict with very same version. So the package manager should have installed fp-units-rtl-3.2.2 (= 3.2.2+dfsg-1) in any circumstance. Unfortunately I could not find the log of that particular build that failed, so unless someone can provide these logs, I'll close this ticket in the coming weeks. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#820708: [Pkg-pascal-devel] Bug#820708: Bug#820708: marked as done (autopkgtest if cge works with current libpng version)
Hi Paul, On Sat, 2021-12-18 at 08:51 +0100, Paul Gevers wrote: > Hi Abou, > > On 18-12-2021 00:21, Debian Bug Tracking System wrote: > > This is an old bug and CGE is known to work with libpng16 since 5.2-3 > > thanks to Michalis patch. > > But if you look at the title, we wanted to add an autopkgtest to catch > the situation in the *future* that this would become a bug again. So I don't see how an auto packaging test will catch such situation. The issue will always happen if CGE is packaged before the transition. And even if it happens, it will not completely render it non usable. Only PNG feature will suffer. More over, as long as I can see in the code, the final fallback is to libpng.so which will always link to the latest version. So it should be OK. > yes, the original bug is closed, but I reused the bug number to add the > autopkgtest [1]. If you have an idea how to test this, please let me know and I can try to implement it. > > I let it up to you to change your mind about closure of this bug. I don't like issues that are open for years. Either we know how to fix it and we do it, or we won't fix it and then we close it as so. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#990224: [Pkg-pascal-devel] Bug#990224: leaves diversion after upgrade from sid to experimental
Hi Paul, Thank you for spotting this out, I did not notice it during my tests before uploading. On Thu, 2021-12-09 at 08:50 +0100, Paul Gevers wrote: > Hi > > As a note, this doesn't look pretty during upgrade: > > Unpacking lazarus-src-2.0 (2.0.12+dfsg-6) over (2.0.12+dfsg-5) ... > Removing 'diversion of > /usr/lib/lazarus/2.0.12/components/codetools/ide/cody.lpk to > /usr/lib/lazarus/2.0.12/components/codetools/ide/cody.lpk.orig by > lazarus-src-2.0' > dpkg-divert: error: rename involves overwriting > '/usr/lib/lazarus/2.0.12/components/codetools/ide/cody.lpk' with > different file > '/usr/lib/lazarus/2.0.12/components/codetools/ide/cody.lpk.orig', not > allowed > dpkg: warning: old lazarus-src-2.0 package post-removal script > subprocess returned error exit status 2 > dpkg: trying script from the new package instead ... > dpkg: ... it looks like that went OK It looks like the logic does not account for upgrading for the same upstream version. This is really annoying and I'll appreciate any help for it. I'm more and more convinced that using arch:all packages for distributing the .lpk files is the right solution for this problem. This diversion stuff looks really ugly. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#997948: Reassign to fp-units-rtl
Control: reassign -1 fp-units-rtl signature.asc Description: This is a digitally signed message part
Bug#997948: [Pkg-pascal-devel] Bug#997948: Bug#997948: winff FTBFS: Fatal: (10022) Can't find unit Interfaces used by winff
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. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#997948: [Pkg-pascal-devel] Bug#997948: winff FTBFS: Fatal: (10022) Can't find unit Interfaces used by winff
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? -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#997948: winff FTBFS: Fatal: (10022) Can't find unit Interfaces used by winff
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 signature.asc Description: This is a digitally signed message part
Bug#981549: [Pkg-pascal-devel] Bug#981549: Bug#981549: lazarus-ide: At startup, a message will appear if it is different from the ver described in version.inc.
Control: fixed -1 2.0.12+dfsg1-1 This issue was fixed on 2.0.12 and nobody was objecting the closure published in last message. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#956956: [Pkg-pascal-devel] Bug#956956: Bug#956956: lazarus: flaky autopkgtest on arm64: EAccessViolation, EInOutError
Bug#981549: [Pkg-pascal-devel] Bug#981549: lazarus-ide: At startup, a message will appear if it is different from the ver described in version.inc.
Th ebehavior of Lazarus 2.0.12 lokks correct for me. If no one minds, I'll close this ticket end of next week if no objection was raised by that time. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#990224: [Pkg-pascal-devel] Bug#990224: Bug#990224: Bug#990224: leaves diversion after upgrade from sid to experimental
Hi Paul and All, On Wed, 2021-11-03 at 10:15 +0100, Abou Al Montacir wrote: > On Tue, 2021-11-02 at 22:52 +0100, Paul Gevers wrote: > > My point is that even if we replace the mechanism, we still need to > > remove the existing diversions from the version in testing, when > > upgrading to the version in unstable. > Sorry, you are right, I totally missed the main point here, that the 2.0.10 is > in stable and in testing, and that we need a solution for the next release > upgrade. > Then, indeed your solution is the way to go, unless it is possible to get the > list of diverted files for 2.0.10 from /var/lib/dpkg/diversions or any other > mean as per example grep lazarus/2.0.10 /var/lib/dpkg/diversions. Can you please have a look at [1] and verify that it fixes this issue. I think I've covered all the cases. [1] https://salsa.debian.org/pascal-team/lazarus/-/commit/471acbe3b95857815a19fe127e7c43429b272b29 -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#997947: [Pkg-pascal-devel] Bug#997947: Bug#997947: doublecmd FTBFS: Fatal: (10022) Can't find unit ExtCtrls used by uCmdBox
Hi Paul, On Thu, 2021-10-28 at 13:53 +0200, Paul Gevers wrote: > If that's the root cause, shouldn't this bug be reassigned to src:fpc > because it's dependencies apparently aren't strict enough (version) wise > and version skew apparently doesn't yield a working installation. I've checked the build dependency of doublecmd and I was surprised that it doesn't depend on fp-compiler. It seems the fp-compiler is pulled implicitly by lcl-utils (for lazbuild) and maybe this is the cause of this mess. Anyway, this does not happe anymore, so let's reduce its severity and assign it to FPC. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
