Bug#793991: lazarus: armel and armhf builds stall
Control: tags 793991 + patch Hi The attached patch works around the problem by disabling '-z relro' for armel and armhf builds. I have tested it on armhf and amd64. Regards Graham disable-relro-on-ARM.debdiff Description: Binary data
Bug#793991: Update on bug#793991: lazarus: armel and armhf builds stall
Hi On 01-09-15 00:04, Abou Al Montacir wrote: >> 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. So at least one difference between your build and mine is that you use "make lazbuild" and I use "debian/rule build". That suggests that we have different LDFLAGS and as such may have found the rootcause. I haven't had time to check this hypothesis, but it is something to think about. This still suggests that an binNMU is not going to solve any problems. Paul signature.asc Description: OpenPGP digital signature
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
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. Paul signature.asc Description: OpenPGP digital signature
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: Update on bug#793991: lazarus: armel and armhf builds stall
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 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. 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?) Question to Abou: - how did you build with debugging symbols on? - how did you install your new packages in order to build the package with your new package on the porterbox? Paul signature.asc Description: OpenPGP digital signature
Bug#793991: lazarus: armel and armhf builds stall
Oh, and by the way, it seems that the potential removal of lazarus and its reverse dependencies is not due to this bug, but because of the fixed bug 777970, see the tracker:https://tracker.debian.org/pkg/lazarus Which is now fixed in testing, so no longer an issue. And if I am correct, as long a we keep on updating THIS bug, the autoremoval will be postponed for this bug. This bug is sid-only so it shouldn't cause an autoremoval anyway (though it will need to be dealt with before the new version of lazarus can migrate).
Bug#793991: lazarus: armel and armhf builds stall
On 10-08-15 11:45, Abou Al Montacir wrote: > Does this give enough info to lower the severity of the bug. Oh, and by the way, it seems that the potential removal of lazarus and its reverse dependencies is not due to this bug, but because of the fixed bug 777970, see the tracker: https://tracker.debian.org/pkg/lazarus And if I am correct, as long a we keep on updating THIS bug, the autoremoval will be postponed for this bug. Paul signature.asc Description: OpenPGP digital signature
Bug#793991: [Pkg-pascal-devel] Bug#793991: lazarus: armel and armhf builds stall
Hi On 10-08-15 11:45, Abou Al Montacir wrote: > Does this give enough info to lower the severity of the bug or to > forward the bug to binutils? I don't know. When I just tried to reproduce Abou's results of yesterday, the ld call doesn't seem to be the problem to me. When I let the process run a little longer (patience) then instead of the last line waiting for ld.bdf I get: (sid_armel-dchroot)elbrus@abel:~/ddrescueview-0.4~alpha2$ ps fux USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND elbrus 25228 0.0 0.1 13332 4724 ?S11:05 0:00 sshd: elbrus@pts/0 elbrus 25229 0.0 0.1 8684 6472 pts/0Ss 11:05 0:00 \_ -bash elbrus8533 0.0 0.0 3504 2816 pts/0S11:23 0:00 -bash elbrus 18706 0.0 0.0 1932 1328 pts/0S12:20 0:00 \_ /usr/bin/make -f debian/rules binary elbrus 18707 1.3 0.1 9152 7444 pts/0S12:20 0:00 | \_ /usr/bin/perl -w /usr/bin/dh binary elbrus 18712 0.0 0.0 1932 1324 pts/0S12:20 0:00 | \_ /usr/bin/make -f debian/rules override_dh_auto_build elbrus 18713 0.0 0.0 1776 336 pts/0S12:20 0:00 | \_ /bin/sh -c lazbuild source/ddrescueview.lpi --bm="GNU/Lin elbrus 18714 2.4 0.3 22128 14052 pts/0Sl 12:20 0:00 | \_ lazbuild source/ddrescueview.lpi --bm=GNU/Linux Relea elbrus 18732 0.0 0.0 0 0 pts/0Z12:20 0:00 | \_ [fpc] elbrus 18749 0.0 0.0 6612 2668 pts/0R+ 12:20 0:00 \_ ps fux Where you can see that lazbuild is waiting for some event to happen (haven't checked, but I assume the line that Graham already mentioned in the upstream bug report). So to be honest, I think it already passed the linker. However, what I noticed is that there is no output to the screen at all during the building by lazbuild, while I expected to see the same text as by manually running fpc. It seems that something in the new file exttools.pas is broken on ARM. Paul signature.asc Description: OpenPGP digital signature
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: 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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793991: [Pkg-pascal-devel] Bug#793991: lazarus: armel and armhf builds stall
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. Paul signature.asc Description: OpenPGP digital signature
Bug#793991: [Pkg-pascal-devel] Bug#793991: lazarus: armel and armhf builds stall
Hi Abou, On 09-08-15 20:39, Abou Al Montacir wrote: >> I'll file a bug upstream. Graham was able to get a little further as well, which is documented in the upstream bug report [1]. > 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? Looking at what Graham already did, it does not appear to help. Paul [1] http://bugs.freepascal.org/view.php?id=28448 signature.asc Description: OpenPGP digital signature
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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793991: lazarus: armel and armhf builds stall
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. [1] http://ddrescueview.sourceforge.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793991: lazarus: armel and armhf builds stall
I built and installed lazarus 1.4.2 but the builds of doublecmd, easymp3gain and cqrlog all failed in the same way as with lazarus 1.4.0. I then attempted to build the daily source snapshot of fpc's fixes tree [1], but many of the patches no longer apply cleanly. [1] ftp://ftp.freepascal.org/pub/fpc/snapshot/fixes/source/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793991: lazarus: armel and armhf builds stall
Source: lazarus Version: 1.4.0+dfsg-3 Severity: serious Control: affects -1 + src:doublecmd src:easymp3gain src:cqrlog Hi Maintainers Since the upload of lazarus 1.4.0+dfsg-3, builds of doublecmd [1], easymp3gain [2] and cqrlog [3] have been stalling on armel and armhf where they built successfully in the past. Basically all packages that build with lazarus that have been uploaded since lazarus. I have tested building doublecmd, easymp3gain and cqrlog on real armhf hardware (NVIDIA Jetson TK1) and against lazarus 1.2.4, 1.2.6 and 1.4.0. The builds succeed against lazarus 1.2.4 and 1.2.6 and fail in exactly the same way as on the buildds against 1.4.0. Tomorrow I will try hacking together a quick build of lazarus 1.4.2 and see if the problem goes away. If not, I will attempt to trace the cause. Regards Graham [1] https://buildd.debian.org/status/package.php?p=doublecmd&suite=unstable [2] https://buildd.debian.org/status/package.php?p=easymp3gain&suite=unstable [3] https://buildd.debian.org/status/package.php?p=cqrlog&suite=unstable -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
