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: doublecmd FTBFS
Control: severity -1 normal 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. 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. 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 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. 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. 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. Paul signature.asc Description: OpenPGP digital signature
Bug#741792: [Pkg-pascal-devel] Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory
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. 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. Regards Graham -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741792: [Pkg-pascal-devel] Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory
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. Paul signature.asc Description: OpenPGP digital signature
Processed: Re: Bug#741792: [Pkg-pascal-devel] Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory
Processing control commands: clone -1 -2 Bug #741792 [src:doublecmd] doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory Bug 741792 cloned as bug 742734 reassign -2 lazarus Bug #742734 [src:doublecmd] doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory Bug reassigned from package 'src:doublecmd' to 'lazarus'. No longer marked as found in versions doublecmd/0.5.8-1. Ignoring request to alter fixed versions of bug #742734 to the same values previously set retitle -2 controls in lazarus/components should be marked auto Bug #742734 [lazarus] doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory Changed Bug title to 'controls in lazarus/components should be marked auto' from 'doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory' -- 741792: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741792 742734: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742734 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741792: [Pkg-pascal-devel] Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory
On 17-03-14 11:50, Graham Inggs wrote: If this is related, I'm not sure whether it needs to be fixed in lazarus or doublecmd. 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. Paul signature.asc Description: OpenPGP digital signature
