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#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#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#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#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#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#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#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#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#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#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#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#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#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
Bug#990224: [Pkg-pascal-devel] Bug#990224: Bug#990224: leaves diversion after upgrade from sid to experimental
Hi Paul 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. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#990224: leaves diversion after upgrade from sid to experimental
Hi Paul, On Tue, 2021-11-02 at 21:22 +0100, Paul Gevers wrote: > ... > I don't follow at all. Sorry, I don't catch what do you mean here, probably due to my non native English. Did you not accept the new solution, or is my explanation above not clear at all and confusing? If you don't like the new solution, it is fine with me. We can try to fix the current one. Otherwise, please let me know and I can try to explain it a bit more. > We're doing diversions in maintainer scripts and > we forget to properly keep track of our diversions. The list of diverted files is created automatically during the build process in lazarus-src.preinst.[1] The very same list is created for lazarus-src.postrm.[2] > With the new > upstream version, apparently some files got dropped and the knowledge of > the diversions got lost in the process. This means that somehow, the lazarus-src.postrm was not called. > I think we can easily manually > drop the diversions now by adding them here [1], while contemplating a > saner and automated way of handling the underlying problem. In the current case, lazarus-src.postrm is not called or is called but does not fall in the list of tests we are doing (called with upgrade?). However, in the past we did not remove the old lazarus when the new one is installed (we were able to have 2.0.10 and 2.0.12). Now we allow this only for major releases, not maintenance ones. So next time, soon, when 2.2 will be there, the upgrade will not happen in the same way. So if upgrading from 2.0.10 to 2.0.x we should remove diversions, but not if we go to from 2.0.10 to 2.y with y > 0. That was why I proposed to completely replace this mechanism with an other one that let it handled automatically with dpkg, but maybe we can just fix the logic in [3]. [1] https://salsa.debian.org/pascal-team/lazarus/-/blob/master/debian/rules#L411 [2] https://salsa.debian.org/pascal-team/lazarus/-/blob/master/debian/rules#L423 [3] https://salsa.debian.org/pascal-team/lazarus/-/blob/master/debian/lazarus-src.postrm.in#L7 -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#997940: view3dscene: FTBFS with fpc 3.2.2
Hi Paul,
On Sat, 2021-10-30 at 15:21 +0200, Paul Gevers wrote:
> So all libraries need a Depends on a binary from src:fpc with an upper
> limit (generated during the build).
In some sense, this is done as any FPC library should depend on RTL package fp-
units-rtl-${UPSTREAM_VERSION} with >= condition.
This implies that if 3.2.2 is introduced instead of 3.2.0 then the library in
the repository is not usable anymore.
However in practice, the upgrade of FPC will leave old version installed and
thus users will be able to continue using old library with old compiler.
> In that way, the Debian
> infrastructure knows that a rebuild (or potentially manual action) is
> needed. We don't want it to be too tight.
I don't know exactly hos Debian infrastructure decides to rebuild or not a
package, but what I can imagine is that view3dscene build depends on castle-
engine (which depends on fp-units-rtl-3.2.0) and on fp-compiler.
In this case fp-compiler will be pulled as 3.2.2 and will drag fp-units-rt-3.2.2
while fp-units-rtl-3.2.0 will be dragged by direct dependency.
In this case, the build system thinks it has got all dependencies but in
reality, ppu files of castle-engine, that are compiled with fp-compiler 3.2.0
will net be usable by 3.2.2 compiler.
> When you said "any new version
> of FPC" do you mean each patch level too, or on only minor level? How
> about Debian new uploads?
For a ppu to be used by the compiler is should:
1. have the same ppu version as the one supported by the compiler. This may
not be the case between different upstream releases.
2. be compiled with an RTL version that have the very same interface for used
units. If any unit from RTL changed interface, then the compiler will fail
to use it and will ask for recompiling the library unit that is using it.
It is important to note that changes of the code of any inline function is
considered as an interface change (think as in C inlines functions are in
.h files).
3. be compiled using -Ur flag to avoid the compiler to try to recompile it if
implementation is changed (this happens usually after a bug fix).
When we upload a new Debian version, we are generally changing implementation.
This is falls under the case number 3. We should be safe and would not need to
recompile anything.
I hope this makes the situation clearer.
--
Cheers, Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
Bug#997940: view3dscene: FTBFS with fpc 3.2.2
Hi Paul, > So, where should this tight dependency be recorded? Should we teach some > binary from castle-game-engine to be strict about some src:fpc counterpart? Normally, any new version of FPC should trigger a rebuild of the entire libraries (not programs) packaged for FPC. The reason is that FPC keeps units interface information in a ppu file that is compiler version depended, but also RTL dependent (each ppu will hold a kind of checksum on used unit files). This is both an advantage and a drawback against C were interface is distributed in a source (header) file. The advantage is that is will be faster, the drawback is that you need a __potential__ rebuild after each compiler/RTL upgrade. > > "Just" rebuilding is not the solution to paper over such an issue, we'd > need to prevent it from going unnoticed next time. It should show up on > https://release.debian.org/transitions/ with an auto-upperlimit-fpc > transition such that the release team is automatically warned that > rebuilds are needed and to prevent fpc from migrating until the rebuild > happened and is ready to migrate too. I don't know for now how to handle this efficiently. but the easiest way is to say, each new upload of FPC triggers all libraries (not programs) rebuild. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#990224: [Pkg-pascal-devel] Bug#990224: lazarus-src-2.0: leaves diversion after upgrade from sid to experimental
The issue here is that LPK files are needed by binary libs (pascal units / ppu) and source packages. The right solution would be probably to move them into a separate packages that is used by both source and binaries. However, that ppu files are distributed not as a unique packages but split into several ones. So this solution will require to double the number or packages required to install full Lazarus installation. Another easier solution would be to make sources depend on binary or binary depend on sources, but this is not something I like, even if, it is true, that in order for Lazarus to show its all power, it needs the sources to be installed. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#997940: [Pkg-pascal-devel] Bug#997940: view3dscene: FTBFS with fpc 3.2.2
Hi Graham, On Wed, 2021-10-27 at 14:05 +0200, Graham Inggs wrote: ... > view3dscene fails to build from source since fpc 3.2.2 was uploaded to > unstable. ... > view3dscene.lpr(55,3) Fatal: Can't find unit CastleUtils used by view3dscene ... I think that we need to re-build CasteEngine in order for that to work. The error message is somewhat misleading. The compiler does not find a unit with the right compiler version. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#964611: libqtpas: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
Hi Paul On Fri, 2020-08-07 at 15:16 +0200, Abou Al Montacir wrote: > I'm going to upload both FPC 3.2.0 and Lazarus 2.0.10. So maybe you can wait > until I upload them before fixing this? I've just pushed new sources for libqtpat 2.6+2.0.10+dfsg. I've verified in cowbuilder that we have the very same issue, so you should not have any particular issue when applying your patch to the new release. Please upload to SID as soon as you are done. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#964611: [Pkg-pascal-devel] Bug#964611: libqtpas: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
Hi Paul, On Fri, 2020-08-07 at 19:55 +0200, Paul Gevers wrote: > Hi, > I am preparing an upload with the symbols file removed as there seems tobe > consensus that using symbols files for C++ projects in Debian isn'tworth the > effort. It will probably require to use 2.0.10 based libQtPas, as I' uploaded both FPC and Lazarus. So 2.0.8 based one will not build anymore. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#964611: [Pkg-pascal-devel] Bug#964611: Bug#964611: libqtpas: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
Hi Peter, On Fri, 2020-08-07 at 11:08 +0100, peter green wrote: > > > +#MISSING: 2.6+2.0.8+dfsg-1# > > > _ZN7QVectorI6QPointE11reallocDataEii6QFlagsIN10QArrayData16AllocationOptionEE@Base > > > 2.6~alpha > > c++filt -n decodes this to > QVector::reallocData(int, int, QFlags) > This looks like an instantiation of a QT template that may or may not be > included in the library as a seperatesymbol depending on whether it gets in- > lined or not. So I believe it should be marked as (optional=templinst) > >> +#MISSING: 2.6+2.0.8+dfsg-1# (optional=templinst) > _Z27qRegisterNormalizedMetaTypeIP7QActionEiRK10QByteArrayPT_N9QtPrivate21MetaTypeDefinedHelperIS5_Xaasr12QMetaTypeId2IS5_E7DefinedntsrSA_9IsBuiltInEE11DefinedTypeE@Base > 2.6~beta-4 > > > +#MISSING: 2.6+2.0.8+dfsg-1# (optional=templinst) > > > _ZN7QVectorI6QPointEC1Ei@Base 2.6~alpha+#MISSING: 2.6+2.0.8+dfsg-1# > > > (optional=templinst)_ZN7QVectorI6QPointEC2Ei@Base 2.6~alpha+#MISSING: > > > 2.6+2.0.8+dfsg-1# (optional=templinst)_ZN7QVectorI7QPointFEC1Ei@Base > > > 2.6~alpha+#MISSING: 2.6+2.0.8+dfsg-1# (optional=templinst)_ZN7QVectorI7QP > > > ointFEC2Ei@Base 2.6~alpha > > These are marked as optional already, so although they show up in the log they > won't actually cause a failure. > > > +#MISSING: 2.6+2.0.8+dfsg-1# > > > _ZN7QVectorIdE11reallocDataEii6QFlagsIN10QArrayData16AllocationOptionEE@Base > > > 2.6~alpha > > c++filt -n decodes this to > QVector::reallocData(int, int, QFlags) > Again this looks like an instantiation of a QT template that may or may not be > included in the library as a seperatesymbol depending on whether it gets in- > lined or not. So again I believe it should be marked as (optional=templinst) > If noone objects i'll prepare a team upload marking the offending symbols as > (optional=templinst) in the next few days. I'm going to upload both FPC 3.2.0 and Lazarus 2.0.10. So maybe you can wait until I upload them before fixing this? -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#944426: [Pkg-pascal-devel] Bug#944426: Bug#944426: Still not able to update
Hi Johann As far as I can see everything is OK. You were updating from 2.0.6-2 to 2.0.6-3 and this was tested here as you can see below. What I can assume is that even your 2.0.6-2 installation was broken and thus the diversion was not done. However this does not explain that your diversions file is OK. Unfortunately, you did force the installation, but if you can reproduce the issue (an other machine, or reinstall -2 then -3) then I'll be happy to reproduce and fix. # aptitude upgrade Resolving dependencies...The following packages will be upgraded: lazarus lazarus-2.0 lazarus-doc-2.0 lazarus-ide lazarus-ide-2.0 lazarus-ide-gtk2-2.0 lazarus-src-2.0 lcl-2.0 lcl-gtk2-2.0 lcl- nogui-2.0 lcl-units-2.0 lcl-utils-2.0 12 packages upgraded, 0 newly installed, 0 to remove and 2 not upgraded.Need to get 0 B/83.8 MB of archives. After unpacking 115 kB will be freed.Do you want to continue? [Y/n/?] ...Reading changelogs... Donegelogs... 7%Preconfiguring packages ...(Reading database ... 545578 files and directories currently installed.)Preparing to unpack .../00- lazarus-2.0_2.0.6+dfsg-3_all.deb ...Unpacking lazarus-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../01-lazarus-ide-2.0_2.0.6+dfsg- 3_amd64.deb ...Unpacking lazarus-ide-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../02-lazarus-ide-gtk2-2.0_2.0.6+dfsg-3_amd64.deb ...Unpacking lazarus-ide-gtk2-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../03-lazarus-ide_2.0.6+dfsg-3_all.deb ...Unpacking lazarus-ide (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../04- lazarus-src-2.0_2.0.6+dfsg-3_all.deb ...Unpacking lazarus-src-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../05-lcl-nogui-2.0_2.0.6+dfsg- 3_amd64.deb ...Unpacking lcl-nogui-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../06-lcl-units-2.0_2.0.6+dfsg-3_amd64.deb ...Unpacking lcl-units-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../07- lcl-gtk2-2.0_2.0.6+dfsg-3_amd64.deb ...Unpacking lcl-gtk2-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../08-lcl-utils-2.0_2.0.6+dfsg- 3_amd64.deb ...Unpacking lcl-utils-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../09-lcl-2.0_2.0.6+dfsg-3_amd64.deb ...Unpacking lcl- 2.0:amd64 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../10- lazarus_2.0.6+dfsg-3_all.deb ...Unpacking lazarus (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Preparing to unpack .../11-lazarus-doc-2.0_2.0.6+dfsg- 3_all.deb ...Unpacking lazarus-doc-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...Setting up lazarus-doc-2.0 (2.0.6+dfsg-3) ...Setting up lazarus-src-2.0 (2.0.6+dfsg-3) ...Setting up lazarus-ide-2.0 (2.0.6+dfsg-3) ...update- alternatives: using /usr/lib/lazarus/2.0.6/startlazarus to provide /usr/bin/lazarus-ide (lazarus-ide) in auto modeSetting up lcl-utils-2.0 (2.0.6+dfsg-3) ...update-alternatives: using /usr/lib/lazarus/2.0.6 to provide /usr/lib/lazarus/default (lazarus) in auto modeSetting up lcl-nogui-2.0 (2.0.6+dfsg-3) ...Setting up lazarus-ide-gtk2-2.0 (2.0.6+dfsg-3) ...update- alternatives: using /usr/lib/lazarus/2.0.6/lazarus-gtk2 to provide /usr/lib/lazarus/2.0.6/lazarus (lazarus-2.0.6) in auto modeSetting up lazarus- ide (2.0.6+dfsg-3) ...Setting up lcl-gtk2-2.0 (2.0.6+dfsg-3) ...Setting up lcl- units-2.0 (2.0.6+dfsg-3) ...Setting up lcl-2.0:amd64 (2.0.6+dfsg-3) ...Setting up lazarus-2.0 (2.0.6+dfsg-3) ...Setting up lazarus (2.0.6+dfsg-3) ...Processing triggers for mime-support (3.62) ...Processing triggers for hicolor-icon-theme (0.17-2) ...Processing triggers for gnome-menus (3.31.4-3) ...Processing triggers for man-db (2.8.5-2) ...Processing triggers for desktop-file-utils (0.23-4) ... Current status: 2 (-12) upgradable.-- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#943600: [Pkg-pascal-devel] Bug#943600: lazarus autopkgtest intermittedly fails due to EAccessViolation: Access violation
Hi Graham, Unfortunately I did not find time to dig into it, but I checked today's failure log and it seems to be related to timeout. Did not check on ARM because of lack of time. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#944426: [Pkg-pascal-devel] Bug#944426: Still not able to update
arus-ide-2.0 2.0.6+dfsg-3dpkg: warning: overriding > problem because --force enabled:dpkg: warning: trying to overwrite > '/usr/lib/lazarus/2.0.6/examples/exploremenu/exploreidemenu.lpk', which is > also in package lazarus-ide-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem > because --force enabled:dpkg: warning: trying to overwrite > '/usr/lib/lazarus/2.0.6/examples/idehelp/demoidehelp.lpk', which is also in > package lazarus-ide-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem because > --force enabled:dpkg: warning: trying to overwrite > '/usr/lib/lazarus/2.0.6/examples/idequickfix/quickfixexample.lpk', which is > also in package lazarus-ide-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem > because --force enabled:dpkg: warning: trying to overwrite > '/usr/lib/lazarus/2.0.6/examples/pascalstream/CopyAsPasPkg/copyformaspascaldem > opkg.lpk', which is also in package lazarus-ide-2.0 2.0.6+dfsg-3dpkg: warning: > overriding problem because --force enabled:dpkg: warning: trying to overwrite > '/usr/lib/lazarus/2.0.6/examples/xmlresource/xmlresource.lpk', which is also > in package lazarus-ide-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem > because --force enabled:dpkg: warning: trying to overwrite > '/usr/lib/lazarus/2.0.6/lcl/interfaces/lcl.lpk', which is also in package lcl- > units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem because --force > enabled:dpkg: warning: trying to overwrite > '/usr/lib/lazarus/2.0.6/lcl/lclbase.lpk', which is also in package lcl-units- > 2.0 2.0.6+dfsg-3dpkg: warning: overriding problem because --force > enabled:dpkg: warning: trying to overwrite > '/usr/lib/lazarus/2.0.6/packager/registration/fcl.lpk', which is also in > package lcl-units-2.0 2.0.6+dfsg-3Setting up lazarus-src-2.0 (2.0.6+dfsg-3) > ... > Bye Hansi > ___Pkg-pascal-devel mailing > listpkg-pascal-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#943600: lazarus autopkgtest intermittedly fails due to EAccessViolation: Access violation
A patch was applied on 2.0.6+dfsg-2 but it seems not completely fixing this issue.Waiting for upstream to fix it properly. -- Cheers, Abou Al Montacir Description: lazbuild fails to build some packages during auto tests. Author: Abou Al Montacir Bug-Debian: http://bugs.debian.org/943600 diff --git a/components/ideintf/ideexterntoolintf.pas b/components/ideintf/ideexterntoolintf.pas index 4654265c..fdf7549f 100644 --- a/components/ideintf/ideexterntoolintf.pas +++ b/components/ideintf/ideexterntoolintf.pas @@ -1229,12 +1229,14 @@ end; procedure TAbstractExternalTool.EnterCriticalSection; begin - FWorkerMessages.EnterCriticalSection; + if Assigned(FWorkerMessages) then +FWorkerMessages.EnterCriticalSection; end; procedure TAbstractExternalTool.LeaveCriticalSection; begin - FWorkerMessages.LeaveCriticalSection; + if Assigned(FWorkerMessages) then +FWorkerMessages.LeaveCriticalSection; end; procedure TAbstractExternalTool.ConsistencyCheck; signature.asc Description: This is a digitally signed message part
Bug#943600: lazarus autopkgtest intermittedly fails due to EAccessViolation: Access violation
Control: forwarded -1 https://bugs.freepascal.org/view.php?id=36318 I've tried to debug this issue but it seems more difficult than I thought. It looks like some class instance is freed twice which results in access violation on the second attempt to free it. Modified code results in the following logs: (1008) 3534 lines compiled, 0.6 sec (1021) 4 warning(s) issued (1022) 30 hint(s) issued (1023) 3 note(s) issued +TAbstractExternalTool.EnterCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.EnterCriticalSection +TAbstractExternalTool.LeaveCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.LeaveCriticalSection Warning: (lazarus) [TLazPackageGraph.ConvertPackageRSTFiles] skipping read only directory /usr/lib/lazarus/2.0.6/components/sparta/dockedformeditor/language/ +TAbstractExternalTool.EnterCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.EnterCriticalSection +TAbstractExternalTool.EnterCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.EnterCriticalSection +TAbstractExternalTool.LeaveCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.LeaveCriticalSection +TAbstractExternalTool.LeaveCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.LeaveCriticalSection +TAbstractExternalTool.EnterCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.EnterCriticalSection +TAbstractExternalTool.EnterCriticalSection: FWorkerMessages = 77A17940 +TAbstractExternalTool.LeaveCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.LeaveCriticalSection +TAbstractExternalTool.EnterCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.EnterCriticalSection +TAbstractExternalTool.EnterCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.EnterCriticalSection +TAbstractExternalTool.LeaveCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.LeaveCriticalSection +TAbstractExternalTool.EnterCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.EnterCriticalSection +TAbstractExternalTool.LeaveCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.LeaveCriticalSection +TAbstractExternalTool.EnterCriticalSection: FWorkerMessages = 77A16DE0 -TAbstractExternalTool.EnterCriticalSection +TAbstractExternalTool.LeaveCriticalSection: FWorkerMessages = 77A16DE0 -TAbstractExternalTool.LeaveCriticalSection +TAbstractExternalTool.EnterCriticalSection: FWorkerMessages = 77A13340 -TAbstractExternalTool.EnterCriticalSection +TAbstractExternalTool.LeaveCriticalSection: FWorkerMessages = 77A13340 -TAbstractExternalTool.LeaveCriticalSection +TAbstractExternalTool.LeaveCriticalSection: FWorkerMessages = 77A17940 -TAbstractExternalTool.LeaveCriticalSection -TAbstractExternalTool.EnterCriticalSection +TAbstractExternalTool.LeaveCriticalSection: FWorkerMessages = Thread 4 "lazbuild" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x77408700 (LWP 11030)] 0x0051ad0b in LEAVECRITICALSECTION (this=0x77649880) at ideexterntoolintf.pas:1240 1240 FWorkerMessages.LeaveCriticalSection; (gdb) I've finally forwarded it to upstream. -- Cheers, Abou Al Montacir $rm -r /tmp/.lazarus ; HOME=/tmp gdb --args ./lazbuild -B --verbose /usr/lib/lazarus/2.0.6/components/sparta/smartformeditor/sparta_smartformeditor.lpk GNU gdb (Debian 8.2.1-2+b1) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./lazbuild...done. (gdb) r Starting program: /mnt/data/mazen/Debian/lazarus/lazbuild -B --verbose /usr/lib/lazarus/2.0.6/components/sparta/smartformeditor/sparta_smartformeditor.lpk [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Parameter: build-all Hint: (lazarus) primary config path: /tmp/.lazarus CopySecondaryConfigFile /etc/lazarus/environmentoptions.xml -> /tmp/.lazarus/environmentoptions.xml Hint: [TPCTargetConfigCache.NeedsUpdate] TargetOS="" TargetCPU="" Options="" compiler file changed "/usr/bin/fpc" FileAg
Bug#944426: [Pkg-pascal-devel] Bug#944426: lazarus-src-2.0 fails to upgrade from 2.0.2+dfsg-7 to 2.0.6+dfsg-1: trying to overwrite filefindlaz.lpk
This is the same issue. This means that my changes do not catch all issues. I'll have a look this WE. For those who want to take a look at the pre-inst script (a few lines) which is probably the bug cause. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#943600: [Pkg-pascal-devel] Bug#943600: lazarus autopkgtest intermittedly fails due to EAccessViolation: Access violation
I finally managed to catch one of these errors on amd64 machine. The issue is that on some packages that are expected to fail, the failure results on an exception.However and despite the expected failure is caught, the test infrastructure detects a message written to stderr and thus triggers the failure. I've rebuilt lazuild using debug symbols, and the error seems to be caught in an object destructor (#3) as shown in the following gdb stack trace:Warning: (lazarus) [TLazPackageGraph.ConvertPackageRSTFiles] skipping read only directory /usr/lib/lazarus/2.0.6/components/sparta/dockedformeditor/language/ Thread 4 "lazbuild" received signal SIGSEGV, Segmentation fault.[Switching to Thread 0x77408700 (LWP 25224)]0x0051ac03 in LEAVECRITICALSECTION (this=0x77649720) at ideexterntoolintf.pas:12371237 FWorkerMessages.LeaveC riticalSection;(gdb) bt#0 0x0051ac03 in LEAVECRITICALSECTION (this=0x77649720) at ideexterntoolintf.pas:1237#1 0x009e9cb5 in SETTHREAD (this=0x77649720, AVALUE=0x0) at exttools.pas:411#2 0x009edc57 in SETTOOL (this=0x7761fc40, AVALUE=0x0) at exttools.pas:1313#3 0x009eeeb1 in DESTROY (this=0x7761fc40, vmt=0x1) at exttools.pas:1612#4 0x0041cd20 in SYSTEM$_$TOBJECT_$__$$_FREE ()#5 0x777a9a80 in ?? ()#6 0x00440cd7 in CLASSES_$$_THREADFUNC$POINTER$$INT64 ()#7 0x7761fc40 in ?? ()#8 0x in ?? ()(gdb) To be continued! -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#943600: lazarus autopkgtest intermittedly fails due to EAccessViolation: Access violation
Hi Graham, On Tue, 2019-11-05 at 10:06 +0200, Graham Inggs wrote: > Hi Abou > On Sun, 3 Nov 2019 at 13:42, Abou Al Montacir wrote: > > I packaged the new upstream 2.0.6, so maybe this issue will disappear. > > It is still present. Yes I noticed that, I'll try to have a deeper look this WE. I'll try to reproduce on the porter box. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#943600: [Pkg-pascal-devel] Bug#943600: lazarus autopkgtest intermittedly fails due to EAccessViolation: Access violation
Hi Paul, I failed to reproduce this issue. Maybe we need to enable debug when compiling for the tests so that we get a comprehensible stack trace. I packaged the new upstream 2.0.6, so maybe this issue will disappear. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#942768: [Pkg-pascal-devel] Bug#942768: lcl-units-2.0: file conflict with lazarus-src-2.0 (versin 2.0.2+dfsg-5)
Control: reopen -1 Hi Alexander, On Wed, 2019-10-23 at 08:34 +0300, Alexander Kernozhitsky wrote: > dpkg: error processing archive /var/cache/apt/archives/lazarus-src- > 2.0_2.0.2+dfsg-6_all.deb (--unpack): trying to > overwrite'/usr/lib/lazarus/2.0.2/components/IdeInspector/ideinspector.lpk', > which isalso in package lcl-units-2.0 2.0.2+dfsg-6 Can you please check on your /var/lib/dpkg/diversions whether you have the following lines:/usr/lib/lazarus/2.0.2/components/IdeInspector/ideinspector.lpk/usr/lib/la zarus/2.0.2/components/IdeInspector/ideinspector.lpk.origlazarus-src-2.0 Can you also tell me you were upgrading from which version? Also if not too much asking, can you please tell me if you remove Lazarus then install it, does it install correctly?-- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#942768: lcl-units-2.0: file conflict with lazarus-src-2.0 (versin 2.0.2+dfsg-5)
Hi Jan, Hi Andreas, > both contains the same file, namely > /usr/lib/lazarus/2.0.2/components/IdeInspector/ideinspector.lpk > and removing it from one of them would fix the issue. That is not a bug, but rather a feature that is solving previous bugs [1] and [2] The issue is that I copied some code from the Debian policy manual [3] and that code was wrong: The given example is missing closing bracket. I should noticed it before, but for some obscure reason it is passing on my computer:if [ upgrade != "$1 || dpkg --compare-versions "$2" lt 1.0-2; then I've checked it again and I've fixed it. Will upload soon. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823706 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898310 [3] https://www.debian.org/doc/debian-policy/ap-pkg-diversions.html-- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#942768: [Pkg-pascal-devel] Bug#942768: lcl-units-2.0: file conflict with lazarus-src-2.0 (versin 2.0.2+dfsg-5)
Hi Jan, Thank you reporting this issue. Can you please provide more information about the issues.Were you installing for the first time or upgrading an old version. In the latter case, what was the old version? Cheers, -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#906349: doublecmd: FTBFS in buster/sid (tries to write in /usr)
Hi Graham, On Mon, 2018-09-24 at 20:48 +0200, Graham Inggs wrote: > Hi Abou > > On 23 September 2018 at 22:44, Abou Al Montacir > wrote: > > I've reverted this in b9ccece9. However this means that Bug#898310 needs to > > be reopen. > > Thanks, I have a reassigned #906349 so it can be closed when lazarus > is uploaded. > Shall I go ahead with an upload, or do you wish to make more changes? Please go ahead and upload. I don't really have time for the moment to fix it correctly. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#906349: [Pkg-pascal-devel] Bug#906349: doublecmd: FTBFS in buster/sid (tries to write in /usr)
Hi Graham, On Fri, 2018-09-21 at 15:40 +0200, Graham Inggs wrote: > Hi Abou > > On 27/08/2018 18:03, Abou Al Montacir wrote: > > Maybe we shall think more about this change. Removing the manually flag > > leads to > > a deeper question: Do we need to distribute LCL units in binary form if they > > will get recompiled anyway? > > Have you had any time to consider this? > > Both doublecmd and ddrescueview have been removed from testing now. I've reverted this in b9ccece9. However this means that Bug#898310 needs to be reopen. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#906349: [Pkg-pascal-devel] Bug#906349: Bug#906349: Bug#906349: doublecmd: FTBFS in buster/sid (tries to write in /usr)
Hi Graham, On Thu, 2018-08-23 at 15:33 +0200, Graham Inggs wrote: > Hi Abou > > On 17/08/2018 18:37, Graham Inggs wrote: > > Abou, do you have an opinion on whether this is a bug in lazarus, or > > does the doublecmd packaging need to be fixed? I just returned back from vacation, let me check this. > The same problem occurs in ddrescueview, reported in #906458. Seems strange > I found it was introduced by the changes to debian/rules in this commit > 'Stop adding manually compiled flag from packages' [1]. That one was proposed to solve a lazarus IDE rebuild issue. I don't like it as I tend to think that units shall be compiled only once and not every time. However the way upstream sees Lazarus distribution is the opposite. I don't see a better way to fix it. > Both doublecmd and ddrescueview build successfully if lazarus-src is > added as a build-dependency. This means that we are missing some PPU/LPK files to be distributed or maybe we are trying to recompile some units and missing some include files. One needs to add -va and look carefully to the log file. > Is this change in behaviour intentional? Somewhat as it was fixing bug#898310 > Should I make these changes to doublecmd and ddrescueview, or is this a > bug in lazarus? Maybe we shall think more about this change. Removing the manually flag leads to a deeper question: Do we need to distribute LCL units in binary form if they will get recompiled anyway? > Regards > Graham > > > [1] > https://salsa.debian.org/pascal-team/lazarus/commit/eb89bf37af1b42215811c132fd > fc919f19126952 -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#897793: [Pkg-pascal-devel] Bug#897793: libqtpas: ftbfs with GCC-8
Hi All, On Sat, 2018-07-21 at 12:16 +0100, peter green wrote: > > > > + _Z27qRegisterNormalizedMetaTypeIP7QActionEiRK10QByteArrayPT_N9QtPr > > ivate21MetaTypeDefinedHelperIS5_Xaasr12QMetaTypeId2IS5_E7DefinedntsrSA_9IsBu > > iltInEE11DefinedTypeE@Base 2.6~beta-4 > > (optional=templinst)_Z30copyPtrIntArrayToQListTemplateIP13QGraphicsItemEvP > > vR5QListIT_E@Base 2.6~alpha > > (optional=templinst)_Z30copyPtrIntArrayToQListTemplateIP13QStandardItemEvP > > vR5QListIT_E@Base 2.6~alpha > > (optional=templinst)_Z30copyPtrIntArrayToQListTemplateIP15QTreeWidgetItemE > > vPvR5QListIT_E@Base 2.6~alpha > > @@ -8820,10 +8821,10 @@ > > (optional=templinst)_ZN5QListIiED1Ev@Base 2.6~alpha > > (optional=templinst)_ZN5QListIiED2Ev@Base 2.6~alpha > > _ZN7QVectorI6QPointE11reallocDataEii6QFlagsIN10QArrayData16AllocationOptio > > nEE@Base 2.6~alpha > > - _ZN7QVectorI6QPointEC1Ei@Base 2.6~alpha > > - _ZN7QVectorI6QPointEC2Ei@Base 2.6~alpha > > - _ZN7QVectorI7QPointFEC1Ei@Base 2.6~alpha > > - _ZN7QVectorI7QPointFEC2Ei@Base 2.6~alpha > > +#MISSING: 2.6~beta-4# _ZN7QVectorI6QPointEC1Ei@Base 2.6~alpha > > +#MISSING: 2.6~beta-4# _ZN7QVectorI6QPointEC2Ei@Base 2.6~alpha > > +#MISSING: 2.6~beta-4# _ZN7QVectorI7QPointFEC1Ei@Base 2.6~alpha > > +#MISSING: 2.6~beta-4# _ZN7QVectorI7QPointFEC2Ei@Base 2.6~alpha > > > > > These symbols seem to be template instantiations, so I believe we > should simply mark them as (optional=templinst). Anyone disagree? > If noone disagrees I will go ahead and upload the change as a > team upload. I'm not 100% sure but it is OK for me. Please go ahead. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#887967: closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)
On Wed, 2018-03-07 at 18:28 +0100, Paul Gevers wrote:
> Hi Graham,
>
> On 07-03-18 16:46, Graham Inggs wrote:
> > On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunk <b...@debian.org> wrote:
> > > This problem is unfortunately still present with fpc 3.0.4+dfsg-14:
> > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgu
> > > i.html
> > >
> >
> > This can be worked around by the following change in debian/rules:
> >
> > -export FPCDIR=/usr/lib/fpc/${FPCDIR}
> > +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default
> >
> > However, it was my understanding that this was supposed to be fixed in
> > FPC, so forwarding to the Pascal list for comment.
>
> No, FPC would fix the default behavior. When FPCDIR is defined in
> debian/rules, it must match. I wonder, does building work without
> defining FPCDIR at all?
I would recommend not defining FPC dir in debian/rules except for the fpc
package itself.
--
Cheers,
Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
Bug#887575: [Pkg-pascal-devel] Bug#887575: Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4
Hi Michalis,
On Thu, 2018-01-18 at 20:56 +0100, Michalis Kamburelis wrote:
> 2018-01-18 14:44 GMT+01:00 Abou Al Montacir <abou.almonta...@sfr.fr>:
> > Doing
> >
> > ./fpmake --globalunitdir="/usr/lib/fpc/3.0.4"
> >
> > Why do we need this? FPC should use the /etc/fpc.cfg to get this, why do we
> > need to explicitly pass this?
> >
>
> Hi Abou,
>
> I think you're very right here -- the option "--globalunitdir XXX"
> should not be needed at all. Specifying $FPCDIR / --globalunitdir
> should only be necessary when the FPC is installed in some custom,
> user-owned location. But when the FPC is installed system-wide (like
> from a Debian package), then nothing (including CGE build script)
> should need to define $FPCDIR or use "--globalunitdir" anymore -- it
> should be picked up by the fpmake system automatically. That's how it
> should work in the upstream FPC, and I know there's an auto-detection
> in fpmkunit for these paths. So, it would be best to fix this issue,
> by fixing that auto-detection mechanism.
I fully agree, I'll try to fix that.
> To be clear: It's not just a matter of having correct /etc/fpc.cfg --
> the fpmake also needs to know the root location of FPC units. (You
> would have to ask fpmake authors why they did it like this.) But that
> is why we have this complication with $FPCDIR or --globalunitdir or
> auto-detecting it.
I've not been fan of fpmake, and I was used to compile my programs directly
using fpc prog.pas.
I understand one need to have some tool to build big projects, but then why not
lazbuild.
OK I'll stop complaining and try to fix this.
> So, we should get to the point where CGE (or any other package
> using fpmake) can be compiled by simple
>
> ~~~
> unset FPCDIR
> fpc fpmake.pp
> ./fpmake # without any additional options like --globalunitdir
> ~~~
Yes, right!
> Looking in the FPC sources, the auto-detection is inside
> packages/fpmkunit/src/fpmkunit.pp , in TFPCDefaults.CompilerDefaults ,
> I'm quoting the relevant lines below. So, someone should adjust it (in
> Debian package) to follow the Debian path conventions :)
Wow! Thanks for this pointer, this saves me valuable time looking where to look
for the bug!
> That's a much better solution than both of my previous suggestions -- thanks!
>
> ~~~
> procedure TFPCDefaults.CompilerDefaults;
> var
> BD : String;
> begin
> inherited CompilerDefaults;
>
> // Use the same algorithm as the compiler, see options.pas
> {$ifdef Unix}
> BD:=FixPath(GetEnvironmentVariable('FPCDIR'), False);
> if BD='' then
> begin
> BD:='/usr/local/lib/fpc/'+FCompilerVersion;
> if not DirectoryExists(BD) and
> DirectoryExists('/usr/lib/fpc/'+FCompilerVersion) then
> BD:='/usr/lib/fpc/'+FCompilerVersion;
%s|usr/lib/fpc|usr/lib/' + FCompilerTargetTriplet + '/fpc|g
> end;
> {$else unix}
> ...
> ~~~
--
Cheers,
Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
Bug#887575: [Pkg-pascal-devel] Bug#887575: Bug#887575: Bug#887575: Bug#887575: castle-game-engine FTBFS with fpc 3.0.4
Hi Michalis, On Thu, 2018-01-18 at 22:25 +0100, Michalis Kamburelis wrote: > 2018-01-18 20:56 GMT+01:00 Michalis Kamburelis <michalis.ka...@gmail.com>: > > So, we should get to the point where CGE (or any other package > > using fpmake) can be compiled by simple > > > > ~~~ > > unset FPCDIR > > fpc fpmake.pp > > ./fpmake # without any additional options like --globalunitdir > > ~~~ > > > > I created a "simplest possible example of using fpmake", so that you > can test it all without dealing with (unrelated) Castle Game Engine > code and Makefiles: > > - Get https://github.com/michaliskambi/simplest-fpmake-test . > - Run "./testme.sh", that just calls "./fpmake". > - I think that we should make it "just work" if user installed FPC > from a Debian package. Without the need to set $FPCDIR, without the > need to pass --globalunitdir . > > Right now, it will not work. Right now, you need to use > --globalunitdir pointing to the proper location when invoking fpmake > (see testme.sh comments). > > (In the previous FPC versions, setting environment variable FPCDIR was > also enough, without the need for --globalunitdir . It doesn't work > for me now, although I see that the code reading $FPCDIR is in > TFPCDefaults.CompilerDefaults. As far as I observed, this was broken > in FPC 3.x upstream, unrelated to Debian.) Thank you for this example. I'll use it to debug this WE and hope we get it fixed by beginning of next week. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#887575: [Pkg-pascal-devel] Bug#887575: castle-game-engine FTBFS with fpc 3.0.4
Hi Michalis, On Thu, 2018-01-18 at 06:43 +0100, Michalis Kamburelis wrote: > The problem is caused by the different directories used by new FPC > 3.0.4 packages (compared to previous versions of FPC in Debian). I must admit that I was expecting many packages to break as the change is too big.But I assume this is worth the pain as now we can install multiple architecture units on the same host. > Doing > > ./fpmake --globalunitdir="/usr/lib/fpc/3.0.4" Why do we need this? FPC should use the /etc/fpc.cfg to get this, why do we need to explicitly pass this? > doesn't work, since /usr/lib/fpc/3.0.4 does not exist. This works: > > ./fpmake --globalunitdir="/usr/lib/x86_64-linux-gnu/fpc/3.0.4" I would use DEB_HOST_MULTIARCH=$(dpkg-architecture -qDEB_HOST_MULTIARCH) > To fix this, I suggest to > > - Change / define the $FPCDIR variable inside Debian build scripts, to > point to the new correct directory. I would try to avoid this if possible but indeed seems correct solution > - Or create a symlink /usr/lib/fpc/3.0.4 -> > /usr/lib/x86_64-linux-gnu/fpc/3.0.4 . This brings us back to pre-MA epoch. Let's avoid it. Also not possible in the Debian auto-builder daemon. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#884163: spamassassin: spamd no longer works correctly after upgrade
Package: spamassassin Version: 3.4.1-6+deb9u1 --- Please enter the report below this line. --- Here I have the same issue:# systemctl status spamassassin.service● spamassassin.service - Perl-based spam filter using text analysis Loaded: loaded (/lib/systemd/system/spamassassin.service; disabled; vendor preset: enabled) Active: inactive (dead) Evolution is keeping filtering inbox (MS exchange with EWS) forever. --- System information. --- Architecture: Kernel: Linux 4.9.0-4-amd64 Debian Release: 9.3 500 unstableriot.im 500 stable wire-app.wire.com 500 stable security.debian.org 500 stable repo.skype.com 500 stable ftp.fr.debian.org 500 stable dl.google.com 500 sid linux.dropbox.com --- Package information. --- Depends(Version) | Installed -+-=== perl | 5.24.1-3+deb9u2 libhtml-parser-perl | 3.72-3 libsocket6-perl | 0.27-1+b1 adduser | 3.115 libsys-hostname-long-perl| 1.5-1 libarchive-tar-perl | libnet-dns-perl | 1.07-1 libnetaddr-ip-perl | 4.079+dfsg-1+b1 libhttp-date-perl| 6.02-1 libmail-dkim-perl| 0.40-1 lsb-base (>= 3.0-6) | 9.20161125 libwww-perl | 6.15-1 OR curl | 7.52.1-5+deb9u3 OR w3m | init-system-helpers (>= 1.18~) | 1.48 Recommends (Version) | Installed ==-+-=== spamc | 3.4.1-6+deb9u1 sa-compile | 3.4.1-6+deb9u1 libmail-spf-perl | 2.9.0-4 libsys-syslog-perl | gnupg | 2.1.18-8~deb9u1 libio-socket-inet6-perl| 2.72-2 Suggests (Version) | Installed -+-=== razor| libio-socket-ssl-perl| 2.044-1 libdbi-perl | pyzor| libcompress-zlib-perl| libencode-detect-perl| libgeo-ip-perl | libnet-patricia-perl | -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#858553: [Pkg-pascal-devel] Bug#858553: [lazarus-doc-1.6] Package lazarus-doc-1.6 is empty and does not ship documentation files
Hi Lazarus Developers List, Can you please help on this issue? fpdoc fails when building Laazarus 1.6.2 documentation. This leads to a serious (RC) bug that may lead to remove Lazarus form next Debian release which will be really a pity. On Sat, 2017-04-01 at 21:45 +0200, Paul Gevers wrote: > First shot at debugging from my side. > > Because the error says: > Exception at 004BDB6C: EDOMError: > EDOMError in DOMDocument.CreateElement. > > I searched for "DOMDocument.CreateElement". Low and behold, I find > something interesting in fpcsrc/packages/fcl-xml/src/dom.pp: > > function TDOMDocument.CreateElement(const tagName: DOMString): TDOMElement; > begin > if not IsXmlName(tagName) then > raise EDOMError.Create(INVALID_CHARACTER_ERR, > 'DOMDocument.CreateElement'); > TDOMNode(Result) := Alloc(TDOMElement); > > Result.Create(Self); > Result.FNSI.QName := FNames.FindOrAdd(DOMPChar(tagName), Length(tagName)); > Result.AttachDefaultAttrs; > end; > > First idea that pops into my mind is: it looks like the source of > lazarus has characters that fp-docs can't convert. Apparently an error > is raised, but converted by fp-docs into exit code 0. > > Interesting to note, is the delta between 2.4.6 and 3.0.0: > - if not IsXmlName(tagName, FXMLVersion = xmlVersion11) then > + if not IsXmlName(tagName) then > which was done in this commit: > http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=20422 > > Sending now as I am about to stop for today, but summary as I currently > suspect the situation is: > 1) fp-doc fails to create error exit code during error > 2) lazarus may have xml files that need updating. > > Probably the next time I spend time on this will be to bisect the > documentation creation to see which file(s) need fixing -> to > potentially solve issue 2 if that is indeed the issue. It looks like the file extctrls.pp or the corresponding xml is not supported by the used version of fpdoc. ]$fpdoc --content=lcl.xct --package=lcl --descr=../../xml/lcl/lcl.xml -- input='../../../lcl/extctrls.pp -Fi../../../lcl/include' --format=html -- descr=../../xml/lcl/extctrls.xmlFPDoc - Free Pascal Documentation ToolVersion 3.0.0 [2017/02/08](c) 2000 - 2003 Areca Systems GmbH / Sebastian Guenther, sg@fr eepascal.org(c) 2005 - 2012 various FPC contributors Writing 757 pages...Exception at 004BDACC: EDOMError:EDOMError in DOMDocument.CreateElement.While with an other page this leads to: $fpdoc --content=lcl.xct --package=lcl --descr=../../xml/lcl/lcl.xml -- input='../../../lcl/interfaces/gtk/gtkwsextctrls.pp -Fi../../../lcl/include' --format=html --descr=../../xml/lcl/interfaces/gtk/gtkwsextctrls.xmlFPDoc - Free Pascal Documentation ToolVersion 3.0.0 [2017/02/08](c) 2000 - 2003 Areca Systems GmbH / Sebastian Guenther, s...@freepascal.org(c) 2005 - 2012 various FPC contributors Writing 128 pages...Using built-in CSS fileCreating plus imageCreating minus imageDone.Here there are no errors. Just goes fine to end. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#858553: [lazarus-doc-1.6] Package lazarus-doc-1.6 is empty and does not ship documentation files
On Sat, 2017-04-01 at 13:15 +0200, Paul Gevers wrote: > I don't remember seeing > any further information from Abou or upstream after the note I quoted above. Sorry, I was unable to look for this due to some personal issues. I'm going to dig in this this week and hope can get rid of it this WE. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#858553: [Pkg-pascal-devel] Bug#858553: [lazarus-doc-1.6] Package lazarus-doc-1.6 is empty and does not ship documentation files
On Thu, 23 Mar 2017 21:20:53 +0100 Paul Gevers <elb...@debian.org> wrote: > Reproducible in Ubuntu, the package is empty there, and in my pbuilder > environment. Looks like build_lcl_docs is broken somehow. > > @Abou, can you take this up with upstream or shine your own light on it? > I have now idea what to do next. Also, do you have any idea what an > Exception isn't returning an error value as exit code? Seems like a > serious fpc or build_lcl_docs issue if you ask me. (I added the > --warnings to avoid any doubt what useful warnings were hidden). > > $ ./build_lcl_docs --outfmt html --warnings > Warning! No corresponding xml file for unit customdrawn_mac.pas ... > interfaces/customdrawn/android/bitmap.pas > Warning! No corresponding xml file for unit OK, I'm going to have a look at the code and guess what it the issue. If I don't manage to get any idea I'll ask upstream. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#858553: [lazarus-doc-1.6] Package lazarus-doc-1.6 is empty and does not ship documentation files
On Thu, 23 Mar 2017 20:27:30 +0100 Paul Gevers <elb...@debian.org> wrote: > On 23-03-17 12:33, Abou Al Montacir wrote: > > The package lazarus-doc-1.6 does not ship any documentation file. > > Not sure if it explains anything, but I see two Exceptions in the build > log¹. I suspect these are the root cause, but I would have expected the > build to fail if that was considered fatal though: > > ... > /interfaces/gtk/gtkwsstdctrls.pp -Fi../../../lcl/include"FPDoc - Free > Pascal Documentation Tool > Version 3.0.0 [2016/09/12] > (c) 2000 - 2003 Areca Systems GmbH / Sebastian Guenther, s...@freepascal.org > (c) 2005 - 2012 various FPC contributors > > Exception at 004BDB6C: EDOMError: > EDOMError in DOMDocument.CreateElement. > > Writing 21499 pages... > 274 Warnings hidden. Use --warnings to see them all. > ./build_lcl_docs --outfmt chm > ... humm, this is a crash in fpdoc. How does the build system not detect it? Maybe the tool itself des not return an error code? > and > > ... > Version 3.0.0 [2016/09/12] > (c) 2000 - 2003 Areca Systems GmbH / Sebastian Guenther, s...@freepascal.org > (c) 2005 - 2012 various FPC contributors > > Exception at 004BDB6C: EDOMError: > EDOMError in DOMDocument.CreateElement. > > Writing 21499 pages... > 274 Warnings hidden. Use --warnings to see them all. > > Somewhat later we have: > /usr/bin/make -C docs/html htmlinstall > INSTALL_PREFIX=/«BUILDDIR»/lazarus-1.6.2+dfsg/debian/tmp2/usr > INSTALL_DOCDIR=/«BUILDDIR»/lazarus- 1.6.2+dfsg/debian/tmp2/usr/share/doc/lazarus/1.6.2 > > Which is the install command from lazarus. That looks all right, except > apparently there were no files to install, because several lines later... > Now scanning > "/«BUILDDIR»/lazarus-1.6.2+dfsg/debian/tmp2/usr/share/doc/lazarus/1.6.2", > found 5 files. > > Paul > > ¹ > https://buildd.debian.org/status/fetch.php?pkg=lazarus=all=1.6.2%2Bdf sg-1=1481146459=0 > OK so fpdoc craches and thus no files are generated. The install dir is empty and the package too. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#858553: [lazarus-doc-1.6] Package lazarus-doc-1.6 is empty and does not ship documentation files
Package: lazarus-doc-1.6 Version: 1.6.2+dfsg-1 Severity: grave --- Please enter the report below this line. --- The package lazarus-doc-1.6 does not ship any documentation file.Running "dpkg -L lazarus-doc-1.6" (see below) shows that almost nothing was packaged.This makes this package completely useless and thus the severity grave. The same command ran on 1.4.4 shows all html files required by Lazarus to display help when one presses F1 key. $dpkg -L lazarus-doc- 1.6/./usr/usr/share/usr/share/doc/usr/share/doc/lazarus/usr/share/doc/lazarus/1. 6.2/usr/share/doc/lazarus/1.6.2/images/usr/share/doc/lazarus/1.6.2/images/laztit le.png/usr/share/doc/lazarus/1.6.2/index.html/usr/share/doc/lazarus/1.6.2/lcl/us r/share/doc/lazarus/1.6.2/lcl/index- 8.html/usr/share/doc/lazarus/1.6.2/lcl/index.html/usr/share/doc/lazarus/1.6.2/lc l/inputfile.txt.gz/usr/share/doc/lazarus-doc-1.6/usr/share/doc/lazarus-doc- 1.6/changelog.Debian.gz/usr/share/doc/lazarus-doc-1.6/copyright/usr/share/doc- base/usr/share/doc-base/lazarus-doc- 1.6/usr/share/lintian/usr/share/lintian/overrides/usr/share/lintian/overrides/la zarus-doc-1.6 --- System information. --- Architecture: Kernel: Linux 4.9.0-2-amd64 Debian Release: 9.0 500 unstableriot.im 500 testing ftp.fr.debian.org 500 stable repo.skype.com 500 stable dl.google.com 500 sid linux.dropbox.com --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Suggests (Version) | Installed ==-+-=== lazarus-ide-1.6| 1.6.2+dfsg-1 -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#842070: libgtk-3-0: Upgrade breaks gvim: Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed
Package: libgtk-3-0 Version: 3.22.3-2 After last update this was gone, so this can probably be closed now. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#829076: general: Random freezes but the mouse can still move
Hi John, On Thu, 30 Jun 2016 11:37:24 +0200 John <john_m...@t-online.de> wrote: > Package: general > Severity: grave > Justification: causes non-serious data loss > > I'm running the current 64-bit Debian with the Cinnamon desktop and have been experiencing 'freezes' for about > a month now. The mouse still moves around but clicking on any window produces no response. However right-clicking > on any window (eg Firefox) brings up the context menu for the desktop!?This looks more like a bug in the window manager rather than a general bug. I'd recommend to reassign it. > > I run a twin-screen set-up and looking at the screens which were timed-out I noticed that the times on the two > screens were different! One was reading 11:03 and the other 11:16!Like if one of the screens stop updating? > > After a few minutes both screens were frozen and I had to Ctrl+Alt+F1, kill the x-session-manager which resulted > in the login screen and the system wsudo gedit /var/log/syslogas usable again.. > > >From this I conclude that the problem is OS-related and not driver-related (as a twin-screen set-up is configured > in the OS).From this I conclude that the OS part (kernel and basic utilities) are still running correctly but the window manager stops dispatching events, maybe due to a buggy program catching the focus and incorrectly handling the X events. I'd recommend again to reassign this bug to the window manager package. There you will probably find a better chance to get help. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#826300: Share knowledge on fpc and powerpc issue
Hi All, On Mon, 2016-08-29 at 11:59 +0200, Abou Al Montacir wrote: ... > Please hold on, upstream fond the issue. > The issue is related to longjump in cprt0.as. > They are going to give us a fix in the next few days. Upstream suggests the following patch which may be temporary:diff --git a/rtl/linux/powerpc/cprt0.as b/rtl/linux/powerpc/cprt0.as index e237d8d..a5672e3 100644 --- a/rtl/linux/powerpc/cprt0.as +++ b/rtl/linux/powerpc/cprt0.as @@ -88,12 +88,8 @@ main_stub: .globl _haltproc .type _haltproc, @function _haltproc: - lis 11, ___fpc_ret@ha - lwz 1, ___fpc_ret@l(11) - addi 1, 1, 16 - lwz 0, 0(1) - mtlr 0 - blr + bl _exit + b _haltproc # li 0, 1 /* exit call */ # lis 3, operatingsystem_result@h -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#826300: [Pkg-pascal-devel] Bug#826300: Bug#826300: Share knowledge on fpc and powerpc issue
Hi All, On Sun, 2016-08-28 at 18:13 +0200, Paul Gevers wrote: > Hi > > On 25-08-16 21:21, Paul Gevers wrote: > > I have a fpc package > > available on debomatic¹ that only for powerpc goes back to the old > > version of fpcmkcf and I confirm that that works. So I agree with > > Graham, that this probably just hides the issue that is to be also found > > elsewhere, at least it would make experimenting easier again if we > > bootstrap powerpc this way. What do you think? > ^^ > > I think it is worthwhile to hack it this way now and fix properly > if/when we find the real root cause. So unless somebody objects (or > beats me to it), I'll probably upload the debomtic hack to unstable next > week that we can use to bootstrap powerpc again. Please hold on, upstream fond the issue. The issue is related to longjump in cprt0.as. They are going to give us a fix in the next few days. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#826300: [Pkg-pascal-devel] Bug#826300: Share knowledge on fpc and powerpc issue
Dear All, It seems that this is now fixed! >Am 22.08.2016 um 12:22 schrieb Florian Klämpfl: >>> Am 22.08.2016 um 10:10 schrieb Florian Klämpfl: >>> Thanks for the reminder, I got stuck with the QEMU setup, but I have >>> finally a running one as well as a fix. If make all works, I will commit it >>> today. >>> >>> >> >> Can you please check if r34366 resolves the problem? >Sorry, I made a mistake, you need r34368 as well. Can anybody test this? -- Cheers, Abou Al Montacir On Thu, 2016-08-18 at 20:50 +0200, Paul Gevers wrote: > Hi all, > > On 12-08-16 22:51, Paul Gevers wrote: > > If no solution to this issue is created soon, I think it is best to > > acknowledge that we (all involved) can't practically fix the issue > > (caused by lack of skills and/or time) and we'll need request removal of > > the whole fpc stack in sid and stretch on powerpc. > > Which I did yesterday. See bug 834644¹. Once that is done, the severity > of this bug can be dropped. > > @Graham, I suggest you also get this done in Ubuntu soon, such that the > next release has the latest fpc from Debian again. > > Paul > > ¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834644 > > ___ > Pkg-pascal-devel mailing list > pkg-pascal-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-pascal-devel signature.asc Description: This is a digitally signed message part
Bug#818663: [Pkg-pascal-devel] Bug#818663: fpc FTBFS on i386.
Hi Peter, On Sat, 2016-03-19 at 14:43 +, peter green wrote: > On 19/03/16 12:26, peter green wrote: > > > > > > This seems to be a result of the recent pic related backports. I'm > > working on a fix now. > ok, the first thing I did was move globtype (which provides TSymStr) > from the implementation uses to the interface uses so it would be > available at that line. > > However I then discovered that the signature of the function in the new > patch did not match the signature of the function it was overriding. > > From the patch: > function a_call_name(list: TAsmList; pd: tprocdef; const s: TSymStr; > const paras: array of pcgpara; forceresdef: tdef; weak: boolean): > tcgpara; override; > > The overridden function. > function a_call_name(list : TAsmList;pd : tprocdef;const s : TSymStr; > forceresdef: tdef; weak: boolean): tcgpara;override; > > The only thing that was done with the parameter was to pass it through > to the inherited function so I simply got rid of it. > > The build then failed with > > /usr/bin/ppc386 -Ur -Xs -O2 -n -Fui386 -Fusystems > -Fu/fpc-3.0.0+dfsg/fpcsrc/rtl/units/i386-linux -Fii386 -FE. > -FUi386/units/i386-linux -dRELEASE > @/fpc-3.0.0+dfsg/debian/deb-host-fpc.cfg -di386 -dGDB -dBROWSERLOG > -Fux86 -Sew pp.pas > hlcgcpu.pas(187,21) Error: Identifier not found "po_external" > hlcgcpu.pas(192,21) Error: Identifier not found "taicpu" > hlcgcpu.pas(232) Fatal: There were 2 errors compiling module, stopping > > That was easy enough to fix, just adding a couple of things to the > implementation uses. > > The result of that was a successful build, I have not done any > functional tests of the result yet. Debdiff attached, if someone else > wants to test and commit/upload feel free to go ahead if not i'll do it > when I get around to it. > > I also notice some junk in the debdiff, presumablly the clean target > needs work. I've pushed your changes to git. Can you please pull and upload or should I upload? -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#818663: [Pkg-pascal-devel] Bug#818663:
On Mon, 2016-03-21 at 08:52 +, Gianfranco Costamagna wrote: > control: tags -1 patch > > Hi Peter, Paul, Abou. > > Do you have any ETA for the upload of the patch? Not really, it depends on available free time, but I'm going to fix that if Peter does not do that before. > As you might have noticed, I'm the one complaining for the fPIC issue on arm*, > and the i386 issue AFAIR is blocking another package too. > > I think the patch in this bug is sane, maybe we can upload it in the next few > days? > I personally like to fix FPC, but I agree with you that if next days none manage to fix it you can proceed. However please give us extra few days, maybe I can find time to fix the error. > thanks a lot, > Welcome, -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#813452: [Pkg-pascal-devel] Bug#813452: [Core] Bug#813452: Bug#813452: fpc-3.0 regression in armhf and armel architectures
Hi Sven, On Mon, 2016-02-22 at 17:44 +0100, Abou Al Montacir wrote: > Hi Sven > > On Mon, 2016-02-22 at 07:58 +0100, Sven Barth wrote: > > > Looks like PIC code was broken in 3.0. Is there anyone aware of that? How > > can we fix that? > > > > > Would you please try the current development version of FPC (3.1.1) to check > > whether the issue persists there? > Yes, sure I'll do and let you know. I've tested the FPC trunk and it works well. Here is the log of both wersions: (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/hedgewars$ fpc -fPIC test2 && ./test2 Free Pascal Compiler version 3.0.0+dfsg-2 [2016/01/28] for arm Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Linux for ARMEL Compiling test2.pas Assembling test Linking test2 /usr/bin/ld.bfd: warning: link.res contains output sections; did you forget -T? 4 lines compiled, 0.3 sec Runtime error 103 at $000101D8 $000101D8 $00010124 (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/hedgewars$ /home/abou/fpc-3.1.1/fpc-3.1.1/build/fpc-3.1.1/fpcsrc/compiler/ppcarm -Fu/home/abou/fpc-3.1.1/fpc-3.1.1/build/fpc-3.1.1/fpcsrc/ -Fu/home/abou/fpc-3.1.1/fpc-3.1.1/build/fpc-3.1.1/fpcsrc/rtl/units/arm-linux -fPIC test2 && ./test2 Free Pascal Compiler version 3.1.1-0 [2016/02/24] for arm Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Linux for ARMEL Compiling test2.pas Linking test2 4 lines compiled, 0.2 sec Hello (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/hedgewars$ This shows that the issue was fixed in trunk. Can you please help finding the revision that may fixed that so we can extract a patch and fix 3.0.0? As long as this bug is open, fpc transition to testing is blocked and this is quite unpleasing for many of our users. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#813452: [Pkg-pascal-devel] Bug#813452: [Core] Bug#813452: Bug#813452: fpc-3.0 regression in armhf and armel architectures
Hi Paul, Hi Gianfranco, On Tue, 2016-02-23 at 20:39 +0100, Paul Gevers wrote: > Hi Gianfranco, > > On 23-02-16 17:18, Gianfranco Costamagna wrote: > > Paul do you have any way to upload a deb file somewhere? (even experimental > > would be awesome) I'm not sure but if you checkout (untar) a snpashot on abel.debian.org and just run make all it would work. I can try to provide a binary, but you will also need RTL. As Paul said, making .deb is probably much more complicated. > Not anytime soon. Getting snapshots into a shape suitable for building > That answers my question in the other mail. > packages was a not so nice experience when Graham and I tried to debug > the relro issue on arm* in the summer of 2015 (I didn't manage before > 3.0.0~rc1 was released). We/I don't have a working way-of-working yet, > so I like to postpone that until close to a new release. I used to keep FPC trunk able to generate .deb snapshots, but I have les and less time to do that. Normally you need to checkout the fpcbuild repository and just replace debian folder by the one from our git. If things did not diverge too much it should work. I'll see if this works for amd64 and puch the changes. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#813452: [Pkg-pascal-devel] Bug#813452: [Core] Bug#813452: Bug#813452: fpc-3.0 regression in armhf and armel architectures
Hi Sven On Mon, 2016-02-22 at 07:58 +0100, Sven Barth wrote: > > Looks like PIC code was broken in 3.0. Is there anyone aware of that? How > can we fix that? > > > Would you please try the current development version of FPC (3.1.1) to check > whether the issue persists there? Yes, sure I'll do and let you know. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#813452: [Pkg-pascal-devel] Bug#813452: Bug#813452: fpc-3.0 regression in armhf and armel architectures
Dear All,
On Mon, 2016-02-22 at 00:32 +0100, Abou Al Montacir wrote:
> Hi Paul,
>
> On Wed, 2016-02-17 at 22:26 +0100, Paul Gevers wrote:
> > Hmm, I was a tiny little bit wrong earlier.
> >
> > I modified hedgewars a tiny bit (patch attached) and build in on
> > debomatic¹. You can see that the failing line reads:
> > "Lua test file specified: /<>/tests/lua/hellfire_burns.lua"
> ...
> > Anyways, it now fails for an access violation. I don't like this at all,
> > but it is hard to say if this is a fpc error or hedgewars'.
> I've tried some simpler code and it looks like the compilation options used by
> hedgewars cause the issue. I don't know if this is normal or not but at least
> we know now that it is not an issue in the code itself but rather in the
> compilation flags.
>
> I'm copying FPC core in case some one can help with the impact of the used
> compilation flags.
>
> Here are my experimentation:
> I first created very small programs:
> (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars$ cat test1.pas
> program test;
> begin
> WriteLn('Hello');
> end.
> (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars$ cat test2.pas
> program test;
> begin
> WriteLn(stdout, 'Hello');
> end.
> (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars$
>
> I first compile using no special flags and both programs execute well:
> (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars$ fpc test1
> Free Pascal Compiler version 3.0.0+dfsg-2 [2016/01/28] for arm
> Copyright (c) 1993-2015 by Florian Klaempfl and others
> Target OS: Linux for ARMEL
> Compiling test1.pas
> Assembling test
> Linking test1
> /usr/bin/ld.bfd: warning: link.res contains output sections; did you forget
> -T?
> 4 lines compiled, 0.3 sec
> (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars$ ./test1
> Hello
> (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars$ fpc test2
> Free Pascal Compiler version 3.0.0+dfsg-2 [2016/01/28] for arm
> Copyright (c) 1993-2015 by Florian Klaempfl and others
> Target OS: Linux for ARMEL
> Compiling test2.pas
> Assembling test
> Linking test2
> /usr/bin/ld.bfd: warning: link.res contains output sections; did you forget
> -T?
> 4 lines compiled, 0.3 sec
> (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars$ ./test2
> Hello
>
> Now, we use a subset of compilation flags from hedgewars and we can just
> reproduce the issue on second program but not the first one:
> (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars$ fpc -FU/home/abou/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars/CMakeFiles/hwengine.dir -k-rpath
> -k'\$ORIGIN/../lib/:\$ORIGIN/:/usr/lib/hedgewars/lib/' -FD/usr/bin -Cs200
> -fPIC -Fl/home/abou/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/bin -k-
> L/usr/lib/arm-linux-gnueabi -Fl/usr/lib/arm-linux-gnueabi -Fl/usr/lib/arm-
> linux-gnueabi -XLAlua=lua5.1 -Fl/usr/lib/arm-linux-gnueabi/libphysfs.so -O2 -g
> -gl -gp -dUSE_VIDEO_RECORDING -dPNG_SCREENSHOTS -dSDL_MIXER_NEWER
> -dSDL_IMAGE_NEWER -dDEBUGFILE test1
> Free Pascal Compiler version 3.0.0+dfsg-2 [2016/01/28] for arm
> Copyright (c) 1993-2015 by Florian Klaempfl and others
> Target OS: Linux for ARMEL
> Compiling test1.pas
> Assembling test
> Linking test1
> /usr/bin/ld.bfd: warning: link.res contains output sections; did you forget
> -T?
> 4 lines compiled, 0.3 sec
> (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars$ ./test1
> Hello
> (sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars$ fpc -FU/home/abou/hedgewars-0.9.22-dfsg/obj-arm-linux-
> gnueabi/hedgewars/CMakeFiles/hwengine.dir -k-rpath
> -k'\$ORIGIN/../lib/:\$ORIGIN/:/usr/lib/hedgewars/lib/' -FD/usr/bin -Cs200
> -fPIC -Fl/home/abou/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/bin -k-
> L/usr/lib/arm-linux-gnueabi -Fl/usr/lib/arm-linux-gnueabi -Fl/usr/lib/arm-
> linux-gnueabi -XLAlua=lua5.1 -Fl/usr/lib/arm-linux-gnueabi/libphysfs.so -O2 -g
> -gl -gp -dUSE_VIDEO_RECORDING -dPNG_SCREENSHOTS -dSDL_MIXER_NEWER
> -dSDL_IMAGE_NEWER -dDEBUGFILE test2
> Free Pascal Compiler version 3.0.0+dfsg-2 [2016/01/28] for arm
> Copyright (c) 1993-2015 by Florian Klaempfl and others
> Target OS: Linux for ARMEL
> Compiling test2.pas
> Assembling test
> Linking test2
> /usr/bin/ld.bfd: warning: link.res contains output sections; did you forget
> -T?
> 4 lines compiled,
Bug#813452: [Pkg-pascal-devel] Bug#813452: fpc-3.0 regression in armhf and armel architectures
Hi Paul,
On Wed, 2016-02-17 at 22:26 +0100, Paul Gevers wrote:
> Hmm, I was a tiny little bit wrong earlier.
>
> I modified hedgewars a tiny bit (patch attached) and build in on
> debomatic¹. You can see that the failing line reads:
> "Lua test file specified: /<>/tests/lua/hellfire_burns.lua"
...
> Anyways, it now fails for an access violation. I don't like this at all,
> but it is hard to say if this is a fpc error or hedgewars'.
I've tried some simpler code and it looks like the compilation options used by
hedgewars cause the issue. I don't know if this is normal or not but at least we
know now that it is not an issue in the code itself but rather in the
compilation flags.
I'm copying FPC core in case some one can help with the impact of the used
compilation flags.
Here are my experimentation:
I first created very small programs:
(sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
gnueabi/hedgewars$ cat test1.pas
program test;
begin
WriteLn('Hello');
end.
(sid
_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
gnueabi/hedgewars$ cat test2.pas
program test;
begin
WriteLn(stdout, 'Hello');
end.
(sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-
gnueabi/hedgewars$
I first compile using no special flags and both programs execute well:
(sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/hedgewars$
fpc test1
Free Pascal Compiler version 3.0.0+dfsg-2 [2016/01/28] for arm
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Linux for ARMEL
Compiling test1.pas
Assembling test
Linking test1
/usr/bin/ld.bfd: warning: link.res contains output sections; did you forget -T?
4 lines compiled, 0.3 sec
(sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/hedgewars$
./test1
Hello
(sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/hedgewars$
fpc test2
Free Pascal Compiler version 3.0.0+dfsg-2 [2016/01/28] for arm
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Linux for ARMEL
Compiling test2.pas
Assembling test
Linking test2
/usr/bin/ld.bfd: warning: link.res contains output sections; did you forget -T?
4 lines compiled, 0.3 sec
(sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/hedgewars$
./test2
Hello
Now, we use a subset of compilation flags from hedgewars and we can just
reproduce the issue on second program but not the first one:
(sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/hedgewars$
fpc
-FU/home/abou/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/hedgewars/CMakeFiles/hwengine.dir
-k-rpath -k'\$ORIGIN/../lib/:\$ORIGIN/:/usr/lib/hedgewars/lib/' -FD/usr/bin
-Cs200 -fPIC -Fl/home/abou/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/bin
-k-L/usr/lib/arm-linux-gnueabi -Fl/usr/lib/arm-linux-gnueabi
-Fl/usr/lib/arm-linux-gnueabi -XLAlua=lua5.1
-Fl/usr/lib/arm-linux-gnueabi/libphysfs.so -O2 -g -gl -gp
-dUSE_VIDEO_RECORDING -dPNG_SCREENSHOTS -dSDL_MIXER_NEWER -dSDL_IMAGE_NEWER
-dDEBUGFILE test1
Free Pascal Compiler version 3.0.0+dfsg-2 [2016/01/28] for arm
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Linux for ARMEL
Compiling test1.pas
Assembling test
Linking test1
/usr/bin/ld.bfd: warning: link.res contains output sections; did you forget -T?
4 lines compiled, 0.3 sec
(sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/hedgewars$
./test1
Hello
(sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/hedgewars$
fpc
-FU/home/abou/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/hedgewars/CMakeFiles/hwengine.dir
-k-rpath -k'\$ORIGIN/../lib/:\$ORIGIN/:/usr/lib/hedgewars/lib/' -FD/usr/bin
-Cs200 -fPIC -Fl/home/abou/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/bin
-k-L/usr/lib/arm-linux-gnueabi -Fl/usr/lib/arm-linux-gnueabi
-Fl/usr/lib/arm-linux-gnueabi -XLAlua=lua5.1
-Fl/usr/lib/arm-linux-gnueabi/libphysfs.so -O2 -g -gl -gp
-dUSE_VIDEO_RECORDING -dPNG_SCREENSHOTS -dSDL_MIXER_NEWER -dSDL_IMAGE_NEWER
-dDEBUGFILE test2
Free Pascal Compiler version 3.0.0+dfsg-2 [2016/01/28] for arm
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: Linux for ARMEL
Compiling test2.pas
Assembling test
Linking test2
/usr/bin/ld.bfd: warning: link.res contains output sections; did you forget -T?
4 lines compiled, 0.3 sec
(sid_armel-dchroot)abou@abel:~/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabi/hedgewars$
./test2
Runtime error 103 at $000101C8
$000101C8 $main, line 3 of test2.pas
It is not clear for me why RTE 103 is thrown, in the second case but not in the
first one. I'd expect either both work or neither. Also I don't see what is the
impact of the compilation flags that are used. Maybe I should perform more
experimentations in order to find a smaller subset. but that will be enough for
tonight!
--
Cheers,
Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
Bug#813452: [Pkg-pascal-devel] Bug#813452: fpc-3.0 regression in armhf and armel architectures
Hi Gianfranco, On Tue, 2016-02-02 at 08:09 +, Gianfranco Costamagna wrote: > Source: fpc > Version: 3.0.0+dfsg-2 > Severity: serious > > > Hi, I open this ticket to discuss with you the regression I found on armel and > armhf platforms > in my hedgewars upload yesterday. > > I checked in a stretch clean pbuilder environment (both logs are attached), > and the testsuite runs correctly, > the only sensible change has been the fpc upgrade, and this is the reason for > this bug report. > > Test project /build/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabihf > Start 1: drillrockets_drill.lua > 1/6 Test #1: drillrockets_drill.lua ...***Failed0.92 sec > An unhandled exception occurred at $000C0300: > EInOutError: File not open > $000C0300 WriteLn, line 467 of /build/hedgewars-0.9.22- > dfsg/hedgewars/uUtils.pas > > > the strange thing is that the affected line seems rather simple: > procedure WriteLn(var f: textfile; s: shortstring); > begin > system.writeln(f, s) > end; > > > and the testsuite works perfectly on every other architecture, so I presume > this is an fpc specific regression. > (I can also ask to remove the hedgewars arm* architectures if needed) I could notice in the build log on sid the following warnings: hwengine.pas(626) Warning: "crtbeginS.o" not found, this will probably cause a linking failure hwen gine.pas(626) Warning: "crtendS.o" not found, this will probably cause a linking failure On the other hand these files seem to belong to libgcc-5-dev on my system $dpkg -S /usr/lib/gcc/x86_64-linux-gnu/5/crtbeginS.o libgcc-5-dev:amd64: /usr/lib/gcc/x86_64-linux-gnu/5/crtbeginS.o Can you please check if they are availables on the arm box you are using? The reason I think these warnings are related is that stdin/stdout are open by parent process so may be related to the C code initialization. I can probably be completely wrong, but let's check this first. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#813452: [Pkg-pascal-devel] Bug#813452: fpc-3.0 regression in armhf and armel architectures
Hi Gianfranco, Glad to support such nice game as hedgewars. On Tue, 2016-02-02 at 08:09 +, Gianfranco Costamagna wrote: > Source: fpc > Version: 3.0.0+dfsg-2 > Severity: serious > > Hi, I open this ticket to discuss with you the regression I found on armel > and armhf platforms > in my hedgewars upload yesterday. > Was not aware that hedgewars was build depending on FPC. Nice to know so that next time we can test before uploading a major release. > I checked in a stretch clean pbuilder environment (both logs are attached), > and the testsuite runs correctly, > the only sensible change has been the fpc upgrade, and this is the reason for > this bug report. > > Test project /build/hedgewars-0.9.22-dfsg/obj-arm-linux-gnueabihf > Start 1: drillrockets_drill.lua > 1/6 Test #1: drillrockets_drill.lua ...***Failed0.92 sec > An unhandled exception occurred at $000C0300: > EInOutError: File not open > $000C0300 WriteLn, line 467 of > /build/hedgewars-0.9.22-dfsg/hedgewars/uUtils.pas > Fine not open? Are you sure the Reset/ReWrite/... open function did not return an error? Maybe check IoResult after opening the file. Anyway this is strange as it would not worked before unless the OS backend open function use is not the same as in previous version. Can you please provide code snippet about when the file was open, which mode and so on? > the strange thing is that the affected line seems rather simple: > procedure WriteLn(var f: textfile; s: shortstring); > begin > system.writeln(f, s) > end; > I'm almost sure this is not the faulty code, but something before that made the file not correctly open. > and the testsuite works perfectly on every other architecture, so I presume > this is an fpc specific regression. > (I can also ask to remove the hedgewars arm* architectures if needed) I don't think we should remove any package form any arch, just be patient and fix the bug. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#793991: [Pkg-pascal-devel] Bug#793991: Bug#793991: Update on bug#793991: lazarus: armel and armhf builds stall
Hi Paul, On Mon, 2015-08-31 at 22:22 +0200, Paul Gevers wrote: > On 27-08-15 18:28, Abou Al Montacir wrote: > > > - how did you install your new packages in order to build the package > > > with your new package on the porterbox? > > I did not install anything, just call the new/old lazbuild with explicit > > file > > path. I tried several times the command proposed by Graham with a small > > modification: > > $ lazbuild source/ddrescueview.lpi # This hangs > > $ ../../lazarus/lazbuild source/ddrescueview.lpi # Works fine > > It doesn't for me. So I am interested to learn what you did. > > I did: > cd lazarus > debian/rules build > cd ../ddrescueview > ../lazarus/lazbuild source/ddrescueview.lpi # This hangs just like a > # normal lazbuild > > > I can reproduce this and send the instructions if needed > > Yes please. Please find attached log file and the executable. Please note that I did not regenerate the executable for the first run as it was still on abel. I preferred to provide it as reference in case new build fails. In second part I regenerated it again and it still works. I can provide the binary if needed. -- Cheers, Abou Al Montacir -- Cheers, Abou Al Montacir sid-debug-793991.log.xz Description: application/xz
Bug#793991: [Pkg-pascal-devel] Bug#793991: Update on bug#793991: lazarus: armel and armhf builds stall
Hi Paul, On Fri, 2015-08-21 at 13:14 +0200, Paul Gevers wrote: Just so everybody can be aware, Graham and me here at Debconf15 have been working on a strategy to tackle this and I have been working on and off the last couple of days to work on the first track with mild success. Graham will hopefully be able to work on the second track when he returns home. Track 1): - Hypothesis: the issue exposes a threading problem in the arm implementation of fpc - This track will only help us to get more upstream involvement and maybe solve the issue in experimental - This may mean that all the build packages on ARM don't work properly anyways if they use threading - Actions1: * Build fpc from the trunk tree (maybe the issue is solved already upstream) * Build lazarus with that * Build a reverse dependency and see that the issue is gone. - Actions2: * Run the reverse dependencies on ARM hardware and see if they work There is already a 3.0.0-RC1 that will be announced this week. So maybe a good way to go is to package it! This may be a good solution to solve this problem. Track 2): - Hypothesis: the new lazbuild implementation is broken on arm - This track can just be applied in the current unstable but is not sustainable in the future. - Actions: * Revert (only) the change in lazbuild * Build a reverse dependency and see that the issue is gone. I'm more confident about compiler/libs issue rather than a lazbuild issue. My experiments on abel porter box showed that we can have a working lazbuild just by recompiling it. Track 3): - Hypothesis: there is an issue with the current optimization on ARM (maybe this explains why the debugging rebuild of Abou run successfully.) - This may be a full solution for Debian - Actions: * Rebuild the whole stack with debugging symbols on (this is the default for c programs in Debian anyways) * Rebuild the whole stack with different optimization (on ARM only?) This could a a valid supposition. In my case I did just recompile lazbuild, I did not try to build the package nor installing it. Question to Abou: - how did you build with debugging symbols on? I did not, at least not forced anything, just apt get sources and then make lazbuild. - how did you install your new packages in order to build the package with your new package on the porterbox? I did not install anything, just call the new/old lazbuild with explicit file path. I tried several times the command proposed by Graham with a small modification: $ lazbuild source/ddrescueview.lpi # This hangs $ ../../lazarus/lazbuild source/ddrescueview.lpi # Works fine I can reproduce this and send the instructions if needed -- Cheers, Abou Al Montacir http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-pascal-devel
Bug#793991: [Pkg-pascal-devel] Bug#793991: lazarus: armel and armhf builds stall
Hi All According to [1] mentioned by Jonas in [2], the bug is in ld from bin utils and is fixed upstream. Does this give enough info to lower the severity of the bug or to forward the bug to binutils? [1] https://sourceware.org/bugzilla/show_bug.cgi?id=18344 [2] http://bugs.freepascal.org/view.php?id=28448 -- Cheers, Abou Al Montacir
Bug#793991: [Pkg-pascal-devel] Bug#793991: lazarus: armel and armhf builds stall
Hi All, On Fri, 2015-07-31 at 12:07 +0200, Graham Inggs wrote: I tried a simpler package, ddrescueview [1], and instead of building the Debian package, I simply ran: lazbuild source/ddrescueview.lpi --bm=GNU/Linux Release As before, the build appeared to stall, and after hitting ctrl-c I noticed that in the background the build had actually completed successfully and there was a working 'ddrescueview' executable. I'll file a bug upstream. I tried this on porterbox abel and reproduced the issue. However I failed to completely understand it. It looks like it hangs when running ld.bfd. Indeed when pressing ctrl+z I got: (sid_armel-dchroot)abou@abel:~/ddrescueview-0.4~alpha2/source$ ps -elf | grep ddrescueview 0 T abou32221 27954 0 80 0 - 5412 signal 18:25 pts/100:00:00 lazbuild ddrescueview.lpi 0 T abou32232 32221 0 80 0 - 178 signal 18:25 pts/100:00:00 /usr/bin/fpc -B -MObjFPC -Schi -CX -Cirot -g -gl -XX -l -vewnhibq -Fl/opt/gnome/lib -Fu/usr/lib/lazarus/1.4.0/lcl/units/arm-linux/gtk2 -Fu/usr/lib/lazarus/1.4.0/lcl/units/arm-linux -Fu/usr/lib/lazarus/1.4.0/components/lazutils/lib/arm-linux -Fu/usr/lib/lazarus/1.4.0/packager/units/arm-linux -Fu/home/abou/ddrescueview-0.4~alpha2/source/ -dLCL -dLCLgtk2 ddrescueview.lpr 0 T abou32233 32232 4 80 0 - 4031 signal 18:25 pts/100:00:03 /usr/bin/ppcarm -B -MObjFPC -Schi -CX -Cirot -g -gl -XX -l -vewnhibq -Fl/opt/gnome/lib -Fu/usr/lib/lazarus/1.4.0/lcl/units/arm-linux/gtk2 -Fu/usr/lib/lazarus/1.4.0/lcl/units/arm-linux -Fu/usr/lib/lazarus/1.4.0/components/lazutils/lib/arm-linux -Fu/usr/lib/lazarus/1.4.0/packager/units/arm-linux -Fu/home/abou/ddrescueview-0.4~alpha2/source/ -dLCL -dLCLgtk2 ddrescueview.lpr 0 T abou32243 32233 5 80 0 - 17728 signal 18:25 pts/100:00:03 /usr/bin/ld.bfd --dynamic-linker=/lib/ld-linux.so.3 --gc-sections -L. -o ddrescueview link.res 0 S abou32249 27954 0 80 0 - 637 pipe_w 18:26 pts/100:00:00 grep ddrescueview when fg and then ctrl+c it seems to resume. I also recompiled lazbuild to get debug symbols, but then I do not have the issue anymore. I even stripped the newly build binary and did not have the issue. So maybe we need just to rebuild again? -- Cheers, Abou Al Montacir -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793991: lazarus: armel and armhf builds stall
H Paul, On Sun, 2015-08-09 at 21:29 +0200, Paul Gevers wrote: Hi On 09-08-15 21:24, Paul Gevers wrote: So maybe we need just to rebuild again? Looking at what Graham already did, it does not appear to help. But maybe it does... the linker was updated yesterday, so maybe that is why your problem didn't appear after stripping. If that is true, we just need a give-back to fix the issue. At least my experiments show that a today's built lazbuild does not suffer from that issue. It could be just a matter of luck, or related to the new linker update, but if this could help avoiding to get Lazarus kicked from testing it is worth tried. We can also try to redirect ld.bfd std err to a grep -v '^ *$' to get rid of blank lines maybe. -- Cheers, Abou Al Montacir -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777622: lazarus contains files licensed under APSL (non-DFSG)
Hi All, The files are pure interfacing files. These are there to allow cross building, but this is not yet supported, so I agree to remove them as a quick fix for Jessie. In the future I'll contact upstream to have a better solution as I want to push for cross compiling support. Cheers, Abou Al Montacir -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749539: [Pkg-pascal-devel] Bug#749539: optgeo: FTBFS don't build depend on versioned lazarus-ide
On Tue, 2014-05-27 at 22:03 +0200, Paul Gevers wrote: Package: optgeo Version: 2.21-2 Severity: serious Justification: fails to build from source (but built successfully in the past) Your package build depends on lazarus-ide-1.2. However, we uploaded lazarus version 1.2.2 to the archive and you package is now blocking the migration to testing as this package does not exist anymore and your package FTBFS. Why something build-depends on lazarus-ide? I'm not aware that the IDE could be used to build in batch mode. Normally one shall use lazbuild which is provided by lcl-utils. Please don't use the versioned package in your build depends. If you have specific requirements, please discuss them on the e-maillist in CC of this bug, so we can improve the lazarus package: pkg-pascal-de...@lists.alioth.debian.org And yes, please use the metapackage unless there are good reasons to depend on a specific lazarus version. Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#748789: view3dscene: FTBFS Can't find unit CastleStringUtils used by CastleUtils
Control: reassign -1 fpc This is not a bug in view3dscene but rather a bug in FPC. Indeed if cge is compiled using -Ur flag that this does not happen. However here the -Ur flag does not have a real meaning as sources are missing. After analyzing more the issue it looks like the CRC stored for CastleUtils in CastleStringUtils differs from the one stored in CastleUtils itself. gshadow locale.alias passwd- services [mazen@karim:~]$ppudump -vi /usr/lib/i386-linux-gnu/fp-units-2.6.4/castle-game-engine-5.0.0/castlestringutils.ppu PPU-Analyser Version 2.6.4 Copyright (c) 1998-2013 by the Free Pascal Development Team Analyzing /usr/lib/i386-linux-gnu/fp-units-2.6.4/castle-game-engine-5.0.0/castlestringutils.ppu (v135) Interface section -- Module Name: CastleStringUtils Source file 1 : castlestringutils.pas 2014/05/06 21:08:10 Source file 2 : norqcheckbegin.inc 2014/05/06 21:08:10 Source file 3 : norqcheckend.inc 2014/05/06 21:08:10 Uses unit: System (Crc: 6A6C800E, IntfcCrc: BFEB7A00, IndCrc: 8B647540) Uses unit: objpas (Crc: 8A1C41DE, IntfcCrc: DBA6773B, IndCrc: 8B647540) Uses unit: sysutils (Crc: 18051831, IntfcCrc: DD662BB4, IndCrc: 373F3F05) Uses unit: CastleUtils (Crc: D8D8A5DB, IntfcCrc: 16456BB1, IndCrc: 0C46E7B4) Uses unit: Classes (Crc: 9ECA0548, IntfcCrc: 7F299AA8, IndCrc: 59A2E37F) Link unit object file: castlestringutils.o (static ) DerefMapsize: 4 DerefMap[0] = CLASSES DerefMap[1] = SYSTEM DerefMap[2] = SYSUTILS DerefMap[3] = REGEXPR Derefdata length: 14145 Interface symtable -- Symtable options: none !! Error in PPU $ppudump -vh /usr/lib/i386-linux-gnu/fp-units-2.6.4/castle-game-engine-5.0.0/castleutils.ppu PPU-Analyser Version 2.6.4 Copyright (c) 1998-2013 by the Free Pascal Development Team Analyzing /usr/lib/i386-linux-gnu/fp-units-2.6.4/castle-game-engine-5.0.0/castleutils.ppu (v135) Header --- Compiler version: 2.6.4 Target processor: i386 Target operating system : Linux-i386 Unit flags : init, final, static_linked, little_endian, release, local_threadvars, local_symtable FileSize (w/o header) : 244378 Checksum: C271DEEF Interface Checksum : 16456BB1 Indirect Checksum : 0C46E7B4 Definitions stored : 884 Symbols stored : 2531 Interface symtable -- Symtable options: none !! Error in PPU As you can see the CRC for CastleUtils is C271DEEF while CastleStringUtils expects 8A1C41DE. This may explain the error message ... Recompiling CastleStringUtils, checksum changed for CastleUtils castlestringutils.pas(77,56) Fatal: Can't find unit CastleStringUtils used by CastleUtils ... Cheers, signature.asc Description: This is a digitally signed message part
Bug#747128: [Pkg-pascal-devel] Bug#747128: castle-game-engine: FTBFS with fpc 2.6.4
Hi Paul, I don't think it is worth to try to fix 4.1.1 as 5.0.0 is out. BTW, why the watch tool did not catch this? I'll work on packaging the new version soon. Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#741792: [Pkg-pascal-devel] Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory
On Thu, 2014-04-10 at 19:27 +0200, Graham Inggs wrote: On 10 April 2014 18:06, Alexander Koblov alexx2...@mail.ru wrote: I suggest the following solution: add also one debian package that will include binary versions of visual components (like SynEdit, that depends on widgetset) compiled for LCL-Qt widgetset (something like lcl-components-qt4). Then programs that wants to compiled for Qt4 simply will add this package in depends so no need in lazarus sources. LCL-Qt was in alpha state some years ago, but now as I see it has same stability like LCL-Gtk2 and in some cases even more stable. Abou, does this sound like a solution? Or is there really only a missing build-depends in doublecmd? LCL components are independent of the widget set used. So I don't see the issue. For the record, I have merged upstream 0.5.9 and relocated doublecmd's git to pkg-pascal [1] (and doublecmd-help [2]). If any patches are forthcoming, please base them on the current git. I'll see if I can help on this, but do not expect anything until FPC 2.6.4 and Lazarus 1.2 are uploaded. Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#741792: [Pkg-pascal-devel] Bug#741792: Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory
I just quickly downloaded .tar.gz and .debian.tar.gz and built it without any issue using latest Lazarus. The only thing is that I have a full installation. This looks like a dependency issue in doublecmd. I'll find out what package is missing if none is candidate to do this. If you think that, either I or Graham will figure it out. I assume you are only talking about Lazarus generated packages right? Paul Hi All, Unfortunately I was not able to reproduce this. Deb files are generated correctly, but I'm using 1.2 and not 1.2~rc2. So this could have solved the issue. Anyway, I really hate recompiling components like synedit. This should not be done. I think we need to make this package enter the standard way to use LCL; Just drop lazarus-src from build dependency and make this build. Cheers, Abou Al Montacir, signature.asc Description: This is a digitally signed message part
Bug#741792: Bug#742734: [Pkg-pascal-devel] Bug#741792: Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory
Hi All, On Tue, 2014-04-01 at 21:34 +0200, Paul Gevers wrote: On 26-03-14 20:15, Paul Gevers wrote: Included *.lpk files in the binary packages and mark them as manually compiled to avoid recompiling them when used. Apparently that causes other side effects for build dependencies. I confirm that NOT marking these packages as manually compiled fixed the FTBFS for doublecmd. I need to analyse more the failure, but the fact that rebuilding a system build binary solves the issue does not mean that the issue is in that binary. It is more like if some program needs to rebuild libc in order to work in Debian, this is of course not a proof that there is a bug in libc Debian package. Abou, can you please comment if you know a way to have the manual trick work for both gtk2 and qt4? Please see my comments on my previous post. (Sorry this thread was badly filtered and I just discovered it) Otherwise, I think I will fix this real soon in Lazarus to prevent removal from jessie. Please don't remove the manual flag. Here, if I understood well, we are dealing about an alpha feature which is QT support in LCL. So it could not be a RC bug. Also upstream changed the way to handle LCL and the user programs should upgrade. Of course as a member of this team; I'll have a look at doublecmd sources and try to fix it, so the way to go now is probably to lower the severity of these bugs or to hope I can close them before the fatal deadline of April 14th. Cheers, signature.asc Description: This is a digitally signed message part
Bug#741792: [Pkg-pascal-devel] Bug#741792: Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory
On Wed, 2014-03-26 at 20:15 +0100, Paul Gevers wrote: Control: clone -1 -2 Control: reassign -2 lazarus Control: retitle -2 controls in lazarus/components should be marked auto On 26-03-14 07:41, Graham Inggs wrote: and the problem with gifanim.pas remains. Alexander then replied as follows: The real problem in lazarus package. Lazarus can not build any LCL-Qt application that uses controls from lazarus/components directory. It is because this components marked as manually build in lazarus debian package (lazarus debian rules file manually change it). In RPM distros (Fedora for example) they marked as automatically build (that is upstream default behavior) so there are no such problem. I make a workaround that worked in previous lazarus versions (forced build of some components from lazarus directory, that you can see in components/build.sh). But now it does not work because they depends on each other. I have confirmed this by simply commenting out the section that builds doublecmd-qt in debian/rules and the doublecmd-gtk package builds without problem. I must admit that I don't understand the details, but this really looks like a bug in lazarus then. Abou, what is your opinion here? The relevant change was made in commit 7c4585ed and the text accompanying it was Included *.lpk files in the binary packages and mark them as manually compiled to avoid recompiling them when used. Apparently that causes other side effects for build dependencies. Hi Paul Others, The decision to mark packages as Manually built was du to the fact that these are considered as provider binaries. So users need to work with them in their binary format. If you remove this, then Lazarus will build them in the user's home directory for each user. There are 2 points here: 1) It not relevant to package binary files if you know it will never be used 2) On multi-user system this is consuming a huge amount of memory useless. 3) It is working only because the source package is installed, while this one is optional. So I don't agree that we need to remove the manual build flag, and I don't agree that this is a critical bug as LC-QT is a alpha feature. I'd ask kindly to lower this bug severity or will do it myself in order to avoid a useless removal from testing scheduled for April 14th. Cheers, Abou Al Montacir, signature.asc Description: This is a digitally signed message part
Bug#741792: [Pkg-pascal-devel] Bug#741792: Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory
Hi All, Control: severity -1 normal Great, On 07-04-14 08:06, Abou Al Montacir wrote: The decision to mark packages as Manually built was due to the fact that these are considered as provider binaries. Clear (an I thought so). Let's call these package library packages. Pascal units are a kind of libraries. If to be compared with C/C++ .ppu files are kind of precompiled headers and .o are pure object files. So users need to work with them in their binary format. Indeed, but it is our task to make sure it actually works (similar to c where you have to state the right include foo.h things). I didn't update the package yet, as you (Abou) seem to have a much clearer picture of fpc and lazarus than I have, that is why I shared my observations. Yes of course, we need to ensure Lazarus is clean and compiling correctly the projects using it. But it could happen that some evolutions break backward compatibility. Here, the main problem I can fond in the logs is: ERROR: package not found: /usr/lib/lazarus/default/ideintf/ideintf.lpk Looking at my laptop I can find: $find /usr/lib/lazarus/default/ -name ideintf.lpk /usr/lib/lazarus/default/components/ideintf/ideintf.lpk So this .lpk file migrated from a location to the other. This is not my decision but upstream's one. If you remove this, then Lazarus will build them in the user's home directory for each user. Ok, let's not do that then, if we can figure out what goes wrong with doublecmd I'll try to build this package, but currently I'm lacking time. There are 2 points here: I assume you added the third one later ;) 1) It not relevant to package binary files if you know it will never be used Ack 2) On multi-user system this is consuming a huge amount of memory useless. Ack (or disk space) 3) It is working only because the source package is installed, while this one is optional. Yeh, right. I can't image that some package build-depends on lazarus-src! Sorry but this is a complete nonsense. So The option of removing Manually is not one. So I don't agree that we need to remove the manual build flag, and I don't agree that this is a critical bug as LC-QT is a alpha feature. Aha, now we are getting somewhere. If this QT thing is Alpha, why doesn't our package description say so. That would make things much clearer. I didn't know this for one thing, and I am building a qt version of my package winff, similar as Graham is doing with his package doublecmd. Do you mean that you will package two versions of WinFF? Does this make sense? I know I was the first who open this door and packages the IDE twice, but now I'm realizing I did a big mistake probably. I really hate that LCL could not build as .so and that could choose that backend at run time. I'd ask kindly to lower this bug severity or will do it myself in order to avoid a useless removal from testing scheduled for April 14th. Done, but it doesn't solve the original problem for doublecmd as a qt package was build in the past. So the question remains, how should projects (or Debian packages) be handling this in a robust way? Apparently depending on the right package is not enough. I can't answer this one right now, but will probably do this in the next days. Paul Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#741792: [Pkg-pascal-devel] Bug#741792: Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory
On Mon, 2014-04-07 at 22:39 +0200, Abou Al Montacir wrote: Apparently depending on the right package is not enough. I can't answer this one right now, but will probably do this in the next days. I just quickly downloaded .tar.gz and .debian.tar.gz and built it without any issue using latest Lazarus. The only thing is that I have a full installation. This looks like a dependency issue in doublecmd. I'll find out what package is missing if none is candidate to do this. Cheers, Abou Al Montacir, signature.asc Description: This is a digitally signed message part
Bug#741792: [Pkg-pascal-devel] Bug#741792: Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory
On Wed, 2014-03-26 at 08:41 +0200, Graham Inggs wrote: On 17 March 2014 21:45, Paul Gevers elb...@debian.org wrote: If I am not much mistaken, you need to fix src/doublecmd.lpi for the new location of the units. I think line 43, but there are better experts on this mail-list. Thanks Paul. I did try changing src/doublecmd.lpi in various ways but was not successful. Alexander (doublcmd's upstream) suggested changing components/build.sh, which I did as follows: --- a/components/build.sh +++ b/components/build.sh @@ -9,7 +9,7 @@ then $lazbuild /usr/lib/lazarus/default/compo nents/lazcontrols/lazcontrols.lpk $DC_ARCH -B $lazbuild /usr/lib/lazarus/default/components/synedit/synedit.lpk $DC_ARCH -B - $lazbuild /usr/lib/lazarus/default/ideintf/ideintf.lpk $DC_ARCH -B + $lazbuild /usr/lib/lazarus/default/components/ideintf/ideintf.lpk $DC_ARCH -B fi # Build components That solved the problem with zvdatetimepickerpropedit.pas but then I got a different error: objectinspector.pp(37,45) Fatal: Can't find unit TreeFilterEdit used by ObjectInspector TExternalToolList.Run Exception: /usr/lib/lazarus/default/components/ideintf/objectinspector.pp(37,45) Fatal: Can't find unit TreeFilterEdit used by ObjectInspector and the problem with gifanim.pas remains. Alexander then replied as follows: The real problem in lazarus package. Lazarus can not build any LCL-Qt application that uses controls from lazarus/components directory. It is because this components marked as manually build in lazarus debian package (lazarus debian rules file manually change it). In RPM distros (Fedora for example) they marked as automatically build (that is upstream default behavior) so there are no such problem. I make a workaround that worked in previous lazarus versions (forced build of some components from lazarus directory, that you can see in components/build.sh). But now it does not work because they depends on each other. That assumption needs proof. If it is true, I will fix it, but for now I'll try to reproduce it. I have confirmed this by simply commenting out the section that builds doublecmd-qt in debian/rules and the doublecmd-gtk package builds without problem. This does not proof that Lazarus is faulty. Cheers, Abou Al Montacir, signature.asc Description: This is a digitally signed message part
Bug#713514: [Pkg-pascal-devel] Need help with lazarus-related bug
On Sun, 2013-09-22 at 10:47 +0200, Paul Gevers wrote: Hi Michael, [I cc'd the pascal devel mail list which is going to be the maintainer of most pascal based packages, including fpc/lazarus itself, please don't respond to me in private, but to that list (Mail-Reply-To set accordingly) I am subscribed.] On 22-09-13 09:36, Michael Hanke wrote: thanks for the pointer! Unfortunately that did not solve the original issue: So far, you didn't explain the original issue :). lazbuild --build-all --ws=gtk2 --pcp=/etc/lazarus mricron.lpi SetPrimaryConfigPath NewValue=/etc/lazarus - /etc/lazarus primary config path: /etc/lazarus/ TLazPackageGraph.OpenDependency: LazarusDir=/usr/lib/lazarus/1.0.10/ The lpl directory is missing. Check that the Lazarus (--lazarusdir) directory is correct. The lpk is missing for dependency=FCL (=1.0) ERROR: Broken dependency: FCL (=1.0) Please check your alternative settings for lazarus and fpc. I recommend them to be set to the highest version of fpc and lazarus that you installed. That is to say, start with checking that /etc/lazarus is actually a symlink to /etc/alternatives/lazarus.cfg. /etc/lazarus is the scp and normally provides all the system installed unti paths it should be changed if you want to keep a particualr version as system default lazarus. However you should know what you want if you do that. Of course, the other thing to check is your build dependencies. Might be that you are missing one (lcl-units ?). I hope Abou can jump in on this discussion, he is much more knowledgeable than me on the exact layout of the different packages. I don't really understand them as I am not enough involved in development of lazarus. this is quite simple: you need to keep the system default lazarus inline with the system default fpc, fp-utils and fpc.cfg That should be all I git cloned your packaging, so I could help debug, but it is not working for me. Do you also have a pristine-tar branch so that I create the tar ball from the git repository? Your get-orig-source target finishes with an error: finishing deferred symbolic links: mricron/mricron.app/Contents/MacOS/mricron - ../../../mricron date: invalid date `28 August 2013\n 32bit\n 64bit' make: *** [get-latest-source] Error 1 Also your clean target fails: paul@wollumbin ~/tmp/mricron $ debian/rules clean dh clean dh_testdir dh_auto_clean debian/rules override_dh_clean make[1]: Entering directory `/media/home/paul/tmp/mricron' find . -name '*.o' -delete -o -name '*.ppu' -delete -o -name '*.a' -delete find . -name '*.compiled' -delete rm mricron.rc mricron.lrs mricron rm: cannot remove `mricron.rc': No such file or directory rm: cannot remove `mricron.lrs': No such file or directory rm: cannot remove `mricron': No such file or directory make[1]: [override_dh_clean] Error 1 (ignored) rm dcm2nii/dcm2nii rm: cannot remove `dcm2nii/dcm2nii': No such file or directory make[1]: [override_dh_clean] Error 1 (ignored) rm dcm2nii/dcm2niigui rm: cannot remove `dcm2nii/dcm2niigui': No such file or directory make[1]: [override_dh_clean] Error 1 (ignored) rm npm/mricron-npm rm: cannot remove `npm/mricron-npm': No such file or directory make[1]: [override_dh_clean] Error 1 (ignored) rm iconfinal-*.xpm mricron.xpm rm: cannot remove `iconfinal-*.xpm': No such file or directory rm: cannot remove `mricron.xpm': No such file or directory make[1]: [override_dh_clean] Error 1 (ignored) dh_clean make[1]: Leaving directory `/media/home/paul/tmp/mricron' And lastly, it is of course possible that you hit a bug in the packaging of lazarus. Maybe we find out here. Paul On Sat, Sep 21, 2013 at 7:50 PM, Paul Gevers elb...@debian.org mailto:elb...@debian.org wrote: On 21-09-13 19:39, Michael Hanke wrote: It seems like a broken build-dependency spec is the reason -- it builds on my laptop, but I can't get it to work in a clean chroot. I wonder whether you could easily spot the problem and help me out? I had a very similar bug reported against my package winff. It has nothing to do with the version of lazarus, but with the way that specific rebuild is done. I fixed it in this [1] commit. Hope this helps. Paul [1] http://anonscm.debian.org/gitweb/?p=pkg-pascal/winff.git;a=commit;h=168a95092d1e3ad2785412b6c60223fa564a8aa7 Cheers, signature.asc Description: This is a digitally signed message part
Bug#717651: fp-compiler-2.6.2: Uninstallable with latest binutils
On Tue, 2013-07-23 at 18:23 +0100, peter green wrote: Guillem Jover wrote: Package: fp-compiler-2.6.2 Version: 2.6.2-2 Severity: serious Hi! This package is no longer installable with the recent binutils upload which has started providing binutils-gold, with fp-compiler-2.6.2 both Depending on binutils and Conflicting on binutils-gold. Here's the relevant binutils changelog entry: ,--- binutils (2.23.52.20130722-1) unstable; urgency=low […] * Stop building the binutils-gold package, let binutils provide binutils-gold. Packages requiring gold should explicity pass -fuse-ld=gold to the compiler, packages requiring the bfd linker should pass -fuse-ld=bfd to the compiler. […] -- Matthias Klose d...@debian.org Mon, 22 Jul 2013 21:13:32 +0200 `--- Assuming that fpc is still broken with gold I suspect that the best way to deal with this is to patch fpc so it calls ld.bfd explicitly and then remove the conflicts as suggested in bug 624525. I think this is the way to do it. I've already discussed with upstream and they don't plan to support gold. Cheers, signature.asc Description: This is a digitally signed message part
Bug#712834: Lazarus FTBFS on armel and armhf
On Thu, 2013-06-20 at 00:28 +0100, peter green wrote: I may try to look into this further if I get a chance but I can't promise anything on timescales. Hi Paul, Hi Peter I think this could be fixed easily. I'll review https://bollin.googlecode.com/svn/lazarus/trunk@5130 and try to commit fix tonight or at least this WE. I'll also integrate 1.0.10 in the same time so we only upload once. Cheers, signature.asc Description: This is a digitally signed message part
Bug#708695: lazarus: contains files with non-free license
On Fri, 2013-05-17 at 21:09 +0200, Paul Gevers wrote: Source: lazarus Version: 0.9.30.4 Severity: serious Tags: upstream Justification: Policy 2.1 The source file contains the following files which I don't believe have a free license: - components/aggpas/arial.ttf - components/aggpas/times.ttf - components/aggpas/timesi.ttf - components/aggpas/verdana.ttf For the font files, I don't think we need them, just link to msttcorefonts should be enough. I don't think shipping these is mandatory but will confirm with upstream. I am sure about the following file (the line about no commercial use): - components/aggpas/gpc/gpc.pas Copyright: (C) 1997, Advanced Interfaces Group, University of Manchester. All rights reserved. This software may be freely copied, modified, and redistributed provided that this copyright notice is preserved on all copies. The intellectual property rights of the algorithms used reside with the University of Manchester Advanced Interfaces Group. You may not distribute this software, in whole or in part, as part of any commercial product without the express consent of the author. There is no warranty or other guarantee of fitness of this software for any purpose. It is provided solely as is. I'll contact upstream about this specific issue and maybe the original author. Cheers, signature.asc Description: This is a digitally signed message part
Bug#704252: preparing the fix
On Fri, 2013-04-12 at 22:48 +0200, Paul Gevers wrote: 1) You used dpkg-architecture -qDEB_BUILD_ARCH instead of dpkg-architecture -qDEB_BUILD_GNU_CPU (you could simplify your rules file as well with this). Hmm, it seems like this was not a smart idea for i386. So the point is that either we have to fix i486 to i386 or amd64 to x86_64... Abou, what is your proposal, and what do you prefer? I can upload again tomorrow. Hi Paul, I'd rather keep what I did as it was the same code used for Lazarus. If there is an issue in the amd64 arch, please report it and I'll try to fix that. There is a translation table in the debian/rules that ensure we get the right arch. This should be probably resolved other way by patching fpcmake and the compiler to conform to debian lib path naming policy. Cheers, signature.asc Description: This is a digitally signed message part
Bug#704252: preparing the fix
On Sun, 2013-04-14 at 08:34 +0200, Paul Gevers wrote: On 14-04-13 01:45, peter green wrote: Sorry I could have been clearer in my last mail. I didn't intend to blame you for most of the issues with the patch (you just took a broken patch and made it differently broken) but I could see how it could have come across that way. Thanks for the clarification, I appreciate that. I like this end :) thanks. Still I firmly belive that the name in the changechangelog trailer should be the person who finalised the upload. Again, I also doubted. I am watching and contributing on the d-mentors@l.d.o list and see this happening once in a while. In this case I wanted to credit Abou for the change, instead, because it failed, it might look otherwise. Indeed, I am now convinced you are right. Next time I will credit in the log itself. If noone naks this in the next few days I will go ahead and upload it. Please go ahead. Lets get rid of this RC bug in Wheezy ASAP, so we can release. If I can help by filing and tracking the unblock after successful build (or I can even do the (unchanged :) ) upload for you), please let me know (here or in private). Sorry for late answer, but It is OK with me too. Cheers, signature.asc Description: This is a digitally signed message part
Bug#704251: Reopen bug#704251
reopen 704251 severity 704251 normal thanks The bug exists really. You just need to have a look at fp-compiler.postinst and will see that the case user choice is not taken into account. Of course it happens that in current version update-alternatives will just issue a warning and returns with 0 as exit code, but this does mean the bug does not exist only by chance. Maybe we can leave with this for wheezy, but should be fixed the correct way anyway. I'm reassessing severity du to above. So please keep open to be fixed for next uploads. Cheers, signature.asc Description: This is a digitally signed message part
Bug#704252: Reopen bug#704252
On Wed, 2013-04-10 at 21:30 +0200, Paul Gevers wrote:
Maybe we can leave with this for wheezy, but should be
fixed anyway. So please keep open to be fixed for next uploads.
I just had a conversation on IRC with the RT, and they like to fix this
in Wheezy if the patch can be small. Abou, I expect something similar to
Lazarus [1]? I will look into creating a patch, but you know the package
a lot better than me, so don't hesitate to come up with something.
Paul
[1] https://code.google.com/p/bollin/source/detail?r=5210#
Hi Paul,
I've already committed this on svn on branch 2.6.0. I'm attaching
patches for info. If you agree I can upload to mentors.
I don't think bug#704251 is mandatory, but if you want I also have its
fix, just did not commit as I'm not sure I'll push it for wheezy.
Cheers,
From 7890fd40c36b6288c20168737e220a7e4cdaf22a Mon Sep 17 00:00:00 2001
From: abou.almonta...@sfr.fr
abou.almonta...@sfr.fr@b4165226-8c1b-0410-80e1-07324e54c907
Date: Tue, 9 Apr 2013 17:27:21 +
Subject: [PATCH 1/3] Fixed typo in French translation. (Closes: Bug#696536)
git-svn-id: https://bollin.googlecode.com/svn/fpc/branches/2.6.0@5215 b4165226-8c1b-0410-80e1-07324e54c907
---
debian/changelog |6 ++
debian/po/fr.po | 12 ++--
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index e97fcb7..9e6a61c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+fpc (2.6.0-8) unstable; urgency=low
+
+ * Fixed typo in French translation. (Closes: Bug#696536)
+
+ -- Abou Al Montacir abou.almonta...@sfr.fr Thu, 27 Dec 2012 08:54:00 +0100
+
fpc (2.6.0-7) unstable; urgency=low
* Proofread templates by debian-l10n-english list. (Closes: Bug#686038)
diff --git a/debian/po/fr.po b/debian/po/fr.po
index 69bd61a..b05196b 100644
--- a/debian/po/fr.po
+++ b/debian/po/fr.po
@@ -7,7 +7,7 @@ msgid
msgstr
Project-Id-Version: fpc\n
Report-Msgid-Bugs-To: f...@packages.debian.org\n
-POT-Creation-Date: 2012-09-03 21:31-0400\n
+POT-Creation-Date: 2012-09-25 19:56+0200\n
PO-Revision-Date: 2012-09-03 21:41-0400\n
Last-Translator: David Prévot da...@tilapin.org\n
Language-Team: French debian-l10n-fre...@lists.debian.org\n
@@ -20,13 +20,13 @@ msgstr
#. Type: boolean
#. Description
-#: ../fp-compiler.templates.in:1001
+#: ../fp-compiler.templates.in:2001
msgid Rename \/etc/fpc.cfg\ to \/etc/fpc.cfg.bak\?
-msgstr Faut-il renommer « /etc/fpc.cfg » en « /etc/fpc.cfg.bak » ?
+msgstr Faut-il renommer « /etc/fpc.cfg » en « /etc/fpc.cfg.bak » ?
#. Type: boolean
#. Description
-#: ../fp-compiler.templates.in:1001
+#: ../fp-compiler.templates.in:2001
msgid
FPC now supports having multiple versions installed on the same system. The
update-alternatives command can be used to set a default version for\n
@@ -43,7 +43,7 @@ msgstr
#. Type: boolean
#. Description
-#: ../fp-compiler.templates.in:1001
+#: ../fp-compiler.templates.in:2001
msgid
Whatever version you may choose as default, the configuration files are
always backward compatible, so it should always be safe to use the latest
@@ -55,7 +55,7 @@ msgstr
#. Type: boolean
#. Description
-#: ../fp-compiler.templates.in:1001
+#: ../fp-compiler.templates.in:2001
msgid
In order to use the alternatives system on the system wide FPC configuration
file you must accept renaming \/etc/fpc.cfg\; otherwise you will need to
--
1.7.10.4
From cf9ef0b076939ff6ad214d0bdb7a3ba4ec7c319a Mon Sep 17 00:00:00 2001
From: abou.almonta...@sfr.fr
abou.almonta...@sfr.fr@b4165226-8c1b-0410-80e1-07324e54c907
Date: Tue, 9 Apr 2013 17:32:11 +
Subject: [PATCH 2/3] Don't remove fpc.*dpkg* the release team don't like it
and as far as I can tell it isn't needed. Update
changelog
git-svn-id: https://bollin.googlecode.com/svn/fpc/branches/2.6.0@5216 b4165226-8c1b-0410-80e1-07324e54c907
---
debian/changelog |7 ++-
debian/fp-compiler.postrm.in |1 -
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 9e6a61c..3f4561d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,13 @@
fpc (2.6.0-8) unstable; urgency=low
+ [ Abou Al Montacir ]
* Fixed typo in French translation. (Closes: Bug#696536)
- -- Abou Al Montacir abou.almonta...@sfr.fr Thu, 27 Dec 2012 08:54:00 +0100
+ [ Peter Michael Green ]
+ * Don't remove fpc.*dpkg* the release team don't like it and
+as far as I can tell it isn't needed.
+
+ -- Abou Al Montacir abou.almonta...@sfr.fr Tue, 26 Mar 2013 09:54:00 +0100
fpc (2.6.0-7) unstable; urgency=low
diff --git a/debian/fp-compiler.postrm.in b/debian/fp-compiler.postrm.in
index 2b89b54..5199a59 100644
--- a/debian/fp-compiler.postrm.in
+++ b/debian/fp-compiler.postrm.in
@@ -13,5 +13,4 @@ if test ${ACTION} = purge
then
rm -f ${CFG_FILE}.cfg
rm -f ${CFG_FILE}.bak
- rm -f ${CFG_FILE}.*dpkg*
fi
--
1.7.10.4
From 89c39be01ec2213eb434290bfaf1580f0dbe3bd6 Mon Sep 17 00
Bug#704252: preparing the fix
On Wed, 2013-04-10 at 23:20 +0200, Paul Gevers wrote: The RT agrees with the patch for this issue. I have not discussed the other items as I think they are not in line with the current freeze exceptions. I can create an upload tomorrow evening. If you want you can prepare that, via mentors, but that is not really needed. From IRC: [23:08] jmw Elbrus: it seems ok to me. the set -ex should become just set -e though Committed Can you please take 2.6.0 branch head and upload. The other 2 items are just a typo in translation file and a fix suggested by release team themselves. I think we really conform to the freeze goals. However if you don't like these two fixes, please feel free to remove them. Thanks, signature.asc Description: This is a digitally signed message part
Bug#704252: Reopen bug#704252
reopen 704252 thanks The bug exists really. You just need to have a look at debian/rules:172 and will see that the debian/control file is systematically rewritten. Of course it happens that current version of debian/control committed in svn exactly matches the output of fixdeb, but this does not mean the bug does not exist. Maybe we can leave with this for wheezy, but should be fixed anyway. So please keep open to be fixed for next uploads. Cheers, signature.asc Description: This is a digitally signed message part
