FTBFS on Debian Buster #3

Closed
opened 3 months ago by deloptes · 28 comments
Collaborator

Basic information

  • TDE version: R14.1.0
  • Distribution: Debian Buster
  • Hardware: amd64

Description

when using debuild -uc -us -b I get FTBFS because sip.h or parser.h are not found.
Indeed these files are in the src directory, but not in the build directory

Steps to reproduce

  1. Updated to latest Debian Buster
  2. cd sip4-tqt
  3. cp tde/1_git/tde/packaging/debian/buster/dependencies/sip4-tqt/debian .
  4. debuild -uc -us -b

Screenshots

<!-- This is a comment. Please fill in the required fields below. The comments provide instructions on how to do so. Note: You do not need to remove comments. --> ## Basic information - TDE version: R14.1.0 - Distribution: Debian Buster - Hardware: amd64 <!-- Use SL/* labels to set the severity level. Please do not set a milestone. --> ## Description when using debuild -uc -us -b I get FTBFS because sip.h or parser.h are not found. Indeed these files are in the src directory, but not in the build directory ## Steps to reproduce 1. Updated to latest Debian Buster 2. cd sip4-tqt 3. cp tde/1_git/tde/packaging/debian/buster/dependencies/sip4-tqt/debian . 4. debuild -uc -us -b ## Screenshots <!-- If it seems useful, please provide provide one or more screenshots. -->
Owner

I created a clean chroot for buster@amd64, used sip4-tqt source package and built it completely without problems. Mentioned sip.h and parser.h were not needed in build directory.

It seems that it may be a problem specific to your system.

I created a clean chroot for buster@amd64, used sip4-tqt source package and built it completely without problems. Mentioned sip.h and parser.h were not needed in build directory. It seems that it may be a problem specific to your system.
Owner

I remember almost 10 years ago I had issues with sip building. The problem was something wrong in my config, not with the package itself. Specifically with how I was copying things around.

http://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydesktop.org/thread/DNRGKPG5HTRYJMP6HTDPI7AFF7YT3MTN/
you can read towards the end, not sure this is your same use case.

I remember almost 10 years ago I had issues with sip building. The problem was something wrong in my config, not with the package itself. Specifically with how I was copying things around. http://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydesktop.org/thread/DNRGKPG5HTRYJMP6HTDPI7AFF7YT3MTN/ you can read towards the end, not sure this is your same use case.
Poster
Collaborator

I remember almost 10 years ago I had issues with sip building. The problem was something wrong in my config, not with the package itself. Specifically with how I was copying things around.

http://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydesktop.org/thread/DNRGKPG5HTRYJMP6HTDPI7AFF7YT3MTN/
you can read towards the end, not sure this is your same use case.

Yes it seems similar.
I don't have the exact output now, but it obviously is missing sip.h and parser.h in the build directory.

I don't understand why it is not working here and working for you there.

Could it be my system is more birgin than yours?

> I remember almost 10 years ago I had issues with sip building. The problem was something wrong in my config, not with the package itself. Specifically with how I was copying things around. > > http://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydesktop.org/thread/DNRGKPG5HTRYJMP6HTDPI7AFF7YT3MTN/ > you can read towards the end, not sure this is your same use case. Yes it seems similar. I don't have the exact output now, but it obviously is missing sip.h and parser.h in the build directory. I don't understand why it is not working here and working for you there. Could it be my system is more birgin than yours?
Owner

uhm.... I am not sure. But Slavek built on Buster recently so we can reasonably exclude a problem with the package. Do you build locally? or in clean chroot environment?

uhm.... I am not sure. But Slavek built on Buster recently so we can reasonably exclude a problem with the package. Do you build locally? or in clean chroot environment?
Poster
Collaborator

Do you build locally? or in clean chroot environment?

I build in chroot environment. I do not understand what you mean by clean.
I purge all packages before building and remove all from the 2_build directory, so I would say "yes, it is clean".

> Do you build locally? or in clean chroot environment? I build in chroot environment. I do not understand what you mean by clean. I purge all packages before building and remove all from the 2_build directory, so I would say "yes, it is clean".
Owner

By "clean" I mean a build environment that does not depend on the local system, so you can verify all the package dependencies are correct. If you use pbuilder you are fine, for example.

By "clean" I mean a build environment that does not depend on the local system, so you can verify all the package dependencies are correct. If you use pbuilder you are fine, for example.
Poster
Collaborator

I use debuild.
As mentioned it builds by default in build-2.7 and dbg-build-2.7, but the sip.h and parser.h files are not there. They are in the sipgen and siplib directories.

IMO it shouldn't matter what builder you use, but God knows.

I use debuild. As mentioned it builds by default in build-2.7 and dbg-build-2.7, but the sip.h and parser.h files are not there. They are in the sipgen and siplib directories. IMO it shouldn't matter what builder you use, but God knows.
Owner

In any case, there is that build-2.7 and dbg-build-2.7 are binary directories == there is only generated files and is correct that there are no header files – neither before the beginning even after the end of build. The need to copy these files indicates that something is wrong on your system.

In any case, there is that `build-2.7` and `dbg-build-2.7` are _binary_ directories == there is only generated files and _is correct_ that there are no header files – neither before the beginning even after the end of build. The need to copy these files indicates that something is wrong on your system.
Owner

IMO it shouldn't matter what builder you use, but God knows.

Agreed, but using correct builders helps minimizing "fake" issues that could show up in unclean/modified build envs. As a sample, in my very first days of building TDE, I was building locally and at some point tdelibs FTBFS for whatever the reason was (I forgot). But build in clean chroot had no issues at all.

> IMO it shouldn't matter what builder you use, but God knows. Agreed, but using correct builders helps minimizing "fake" issues that could show up in unclean/modified build envs. As a sample, in my very first days of building TDE, I was building locally and at some point tdelibs FTBFS for whatever the reason was (I forgot). But build in clean chroot had no issues at all.
Poster
Collaborator

I think a code for Debian should build with Debian standard builder such as debuild

Here is the exact error and my question is why in your pbuilder or sbuilder or whatever case this is not happening.

I think my claim is legitim.

touch dbg-build-2.7/configure-stamp
dh_testdir
/usr/bin/make -C dbg-build-2.7
make[1]: Entering directory '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/dbg-build-2.7'
gcc -c -O2 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o export.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/export.c
make[2]: Entering directory '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/dbg-build-2.7/sipgen'
gcc -c -O0 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o main.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/main.c
gcc -c -O0 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o transform.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/transform.c
gcc -c -O0 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o gencode.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/gencode.c
gcc -c -O2 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o heap.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/heap.c
yacc  /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/parser.y
/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/parser.y: warning: 2 shift/reduce conflicts [-Wconflicts-sr]
mv -f y.tab.c parser.c
lex  -t /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/lexer.l > lexer.c
gcc -c -O2 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o parser.o parser.c
gcc -c -O0 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o export.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/export.c
/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/parser.y:24:10: fatal error: sip.h: No such file or directory
 #include "sip.h"
          ^~~~~~~
compilation terminated.
make[2]: *** [Makefile:31: parser.o] Error 1
make[2]: *** Waiting for unfinished jobs....
gcc -c -O0 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o heap.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/heap.c
yacc  /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/parser.y
lex  -t /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/lexer.l > lexer.c
gcc -c -O0 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o lexer.o lexer.c
/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/parser.y: warning: 2 shift/reduce conflicts [-Wconflicts-sr]
/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/lexer.l:25:10: fatal error: sip.h: No such file or directory
 #include "sip.h"
          ^~~~~~~
compilation terminated.
make[2]: *** [Makefile:31: lexer.o] Error 1
make[2]: *** Waiting for unfinished jobs....
mv -f y.tab.c parser.c
make[2]: Leaving directory '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/dbg-build-2.7/sipgen'
make[1]: *** [Makefile:3: all] Error 2
make[1]: Leaving directory '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/dbg-build-2.7'
make: *** [debian/rules:76: dbg-build-2.7/build-stamp] Error 2
make: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/build-2.7/sipgen'
make[1]: *** [Makefile:3: all] Error 2
make[1]: Leaving directory '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/build-2.7'
make: *** [debian/rules:71: build-2.7/build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -b -j4 failed
make: *** [mk/Makefile.builds:112: /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt.step-build] Error 29
I think a code for Debian should build with Debian standard builder such as debuild Here is the exact error and my question is why in your pbuilder or sbuilder or whatever case this is not happening. I think my claim is legitim. ``` touch dbg-build-2.7/configure-stamp dh_testdir /usr/bin/make -C dbg-build-2.7 make[1]: Entering directory '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/dbg-build-2.7' gcc -c -O2 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o export.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/export.c make[2]: Entering directory '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/dbg-build-2.7/sipgen' gcc -c -O0 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o main.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/main.c gcc -c -O0 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o transform.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/transform.c gcc -c -O0 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o gencode.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/gencode.c gcc -c -O2 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o heap.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/heap.c yacc /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/parser.y /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/parser.y: warning: 2 shift/reduce conflicts [-Wconflicts-sr] mv -f y.tab.c parser.c lex -t /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/lexer.l > lexer.c gcc -c -O2 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o parser.o parser.c gcc -c -O0 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o export.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/export.c /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/parser.y:24:10: fatal error: sip.h: No such file or directory #include "sip.h" ^~~~~~~ compilation terminated. make[2]: *** [Makefile:31: parser.o] Error 1 make[2]: *** Waiting for unfinished jobs.... gcc -c -O0 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o heap.o /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/heap.c yacc /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/parser.y lex -t /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/lexer.l > lexer.c gcc -c -O0 -g -I/usr/include/tqt -I/usr/include/tqt3 -I/usr/include/qt3 -w -DNDEBUG -I. -o lexer.o lexer.c /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/parser.y: warning: 2 shift/reduce conflicts [-Wconflicts-sr] /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/sipgen/lexer.l:25:10: fatal error: sip.h: No such file or directory #include "sip.h" ^~~~~~~ compilation terminated. make[2]: *** [Makefile:31: lexer.o] Error 1 make[2]: *** Waiting for unfinished jobs.... mv -f y.tab.c parser.c make[2]: Leaving directory '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/dbg-build-2.7/sipgen' make[1]: *** [Makefile:3: all] Error 2 make[1]: Leaving directory '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/dbg-build-2.7' make: *** [debian/rules:76: dbg-build-2.7/build-stamp] Error 2 make: *** Waiting for unfinished jobs.... make[2]: Leaving directory '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/build-2.7/sipgen' make[1]: *** [Makefile:3: all] Error 2 make[1]: Leaving directory '/mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt/build-2.7' make: *** [debian/rules:71: build-2.7/build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 debuild: fatal error at line 1182: dpkg-buildpackage -us -uc -ui -b -j4 failed make: *** [mk/Makefile.builds:112: /mnt/DEVELOPMENT/TDE/repo-master/tde/2_build/dependencies/sip4-tqt.step-build] Error 29 ```
Owner

I think a code for Debian should build with Debian standard builder such as debuild

Hi Emanoil,
I agreed on this. As a test, I tried a local build using debuild and it builds fine (again, bookworm not buster, but I don't expect this to be the issue).

Before you run debuild, can you check this from the sip folder?:

prompt> find . -type f -iname "sip.h"
./sipgen/sip.h
./siplib/sip.h

I even tried following your exact steps instead of using my scripts, again success.
I am really not sure what is the problem, but everything seems to point to the fact that it is related to your system.

> I think a code for Debian should build with Debian standard builder such as debuild Hi Emanoil, I agreed on this. As a test, I tried a local build using debuild and it builds fine (again, bookworm not buster, but I don't expect this to be the issue). Before you run debuild, can you check this from the sip folder?: ``` prompt> find . -type f -iname "sip.h" ./sipgen/sip.h ./siplib/sip.h ``` I even tried following your exact steps instead of using my scripts, again success. I am really not sure what is the problem, but everything seems to point to the fact that it is related to your system.
Owner

btw, is your log above the full log? I see more things going on here, specifically entering the sipgen and siplib folders at the beginning.

btw, is your log above the full log? I see more things going on here, specifically entering the sipgen and siplib folders at the beginning.
Poster
Collaborator

Hi,
I pasted only the relevant part of the log for target dbg-build-2.7/configure-stamp and build-2.7/build-stamp.

Can you check if the sip.h is in sipgen under dbg-build-2.7/sipgen or build-2.7/sipgen

It could be that I am missing some switch on my system that you have already enabled and is outside of the build tree

I have sip.h in the source tree but not under the build targets specified

find tde/2_build/dependencies/sip4-tqt -name sip.h
tde/2_build/dependencies/sip4-tqt/siplib/sip.h
tde/2_build/dependencies/sip4-tqt/sipgen/sip.h

Could it be that I have older version of the packaging code?

thanks

Hi, I pasted only the relevant part of the log for target dbg-build-2.7/configure-stamp and build-2.7/build-stamp. Can you check if the sip.h is in sipgen under dbg-build-2.7/sipgen or build-2.7/sipgen It could be that I am missing some switch on my system that you have already enabled and is outside of the build tree I have sip.h in the source tree but not under the build targets specified ``` find tde/2_build/dependencies/sip4-tqt -name sip.h tde/2_build/dependencies/sip4-tqt/siplib/sip.h tde/2_build/dependencies/sip4-tqt/sipgen/sip.h ``` Could it be that I have older version of the packaging code? thanks
Owner

I have sip.h in the source tree but not under the build targets specified

sip.h is in the same locations that you have.

Could it be that I have older version of the packaging code?

Unlikely, no much changes there for long I guess. Anyway you can just checkout the latest packaging files to be sure.

Here is the simplest non-clean way I tested.

  1. using mc, copy sip4-tqt folder to build folder (F5 command, not CLI)
  2. using mc, copy sip4-tqt debian folder from packaging files to sip4-tqt build folder (F5 command, not CLI)
  3. cd into sip4-tqt build folder
  4. run 'debuild -uc -us -b'
    Builds fine. Attached console output.
> I have sip.h in the source tree but not under the build targets specified sip.h is in the same locations that you have. >Could it be that I have older version of the packaging code? Unlikely, no much changes there for long I guess. Anyway you can just checkout the latest packaging files to be sure. Here is the simplest non-clean way I tested. 1. using mc, copy sip4-tqt folder to build folder (F5 command, not CLI) 2. using mc, copy sip4-tqt debian folder from packaging files to sip4-tqt build folder (F5 command, not CLI) 3. cd into sip4-tqt build folder 4. run 'debuild -uc -us -b' Builds fine. Attached console output.
Poster
Collaborator

Please check (kdiff3) my log and yours and tell me if you see what I see :)

thank you in advance

Please check (kdiff3) my log and yours and tell me if you see what I see :) thank you in advance
Poster
Collaborator

and here the log when no -j4 is used

I mean I do not see anywhere in your log yacc being called

how is this possible

and here the log when no -j4 is used I mean I do not see anywhere in your log yacc being called how is this possible
Owner

Bison / flex / yacc is not listed in Build-Depends and therefore on a clean chroot is not installed => cannot be called during build. This confirms that on your system is the package built in other conditions and therefore causes other behavior.

Bison / flex / yacc is not listed in Build-Depends and therefore on a clean chroot is not installed => cannot be called during build. This confirms that on your system is the package built in other conditions and therefore causes other behavior.
Owner

I have bison/flex/byacc install on my machine, so I guess it must be something else.

@deloptes your log and mine are quite different. To help troubleshooting, could you follow exactly the steps I listed here and compare the log files in that case?

I have bison/flex/byacc install on my machine, so I guess it must be something else. @deloptes your log and mine are quite different. To help troubleshooting, could you follow exactly the steps I listed [here](https://mirror.git.trinitydesktop.org/gitea/TDE/sip4-tqt/issues/3#issuecomment-16260) and compare the log files in that case?
Owner

for some reasons, in your log yacc gets called, while it does not happen here or in a chroot env. Doing a 1 to 1 comparison using the same building steps may help.

for some reasons, in your log yacc gets called, while it does not happen here or in a chroot env. Doing a 1 to 1 comparison using the same building steps may help.
Owner

It seems that on your machine, for some reason in your Makefile, rules are generated to regenerate parser and lexer from .l and .y files. And these rules do not work properly.

In Readme it is mentioned that build.py is used for this purpose, but it is not part of the source code. configure.py does not specify any bison / flex / yacc related rules. Currently, I do not know what causes that these rules are generated to your Makefile.

It seems that on your machine, for some reason in your Makefile, rules are generated to regenerate parser and lexer from `.l` and `.y` files. And these rules do not work properly. In Readme it is mentioned that `build.py` is used for this purpose, but it is not part of the source code. `configure.py` does not specify any bison / flex / yacc related rules. Currently, I do not know what causes that these rules are generated to your Makefile.
Poster
Collaborator

I have bison/flex/byacc install on my machine, so I guess it must be something else.

@deloptes your log and mine are quite different. To help troubleshooting, could you follow exactly the steps I listed here and compare the log files in that case?

These are basically the steps I also use

  1. copy the code from 1_git....tde/main
  2. copy the package debian from 1_git/tde/packaging
  3. cd to the directory and invoke debuild ...

I think it must be something related to what Slavek said, that something is causing the files to be regenerated.

> I have bison/flex/byacc install on my machine, so I guess it must be something else. > > @deloptes your log and mine are quite different. To help troubleshooting, could you follow exactly the steps I listed [here](https://mirror.git.trinitydesktop.org/gitea/TDE/sip4-tqt/issues/3#issuecomment-16260) and compare the log files in that case? These are basically the steps I also use 1. copy the code from 1_git....tde/main 2. copy the package debian from 1_git/tde/packaging 3. cd to the directory and invoke debuild ... I think it must be something related to what Slavek said, that something is causing the files to be regenerated.
Owner

I think it must be something related to what Slavek said, that something is causing the files to be regenerated.

There is definitely something there triggering yacc on your side, which is not happening here or in a clean env.

> I think it must be something related to what Slavek said, that something is causing the files to be regenerated. There is definitely something there triggering yacc on your side, which is not happening here or in a clean env.
Poster
Collaborator

yes, this seems to be a criminal case :)

usually in the Makefile a rule is invoked when the file is missing.

I wonder how it works on your side, but perhaps we put it on ice and I use a local patch when building :/

yes, this seems to be a criminal case :) usually in the Makefile a rule is invoked when the file is missing. I wonder how it works on your side, but perhaps we put it on ice and I use a local patch when building :/
Owner

Well, sure you can use a local patch, although I would investigare what why it is different on your side. Perhaps when cmake conversion is completed, all this problem will simply go away 😄

Should we close this issue and the related PR?

Well, sure you can use a local patch, although I would investigare what why it is different on your side. Perhaps when cmake conversion is completed, all this problem will simply go away :smile: Should we close this issue and the related PR?
Poster
Collaborator

I close the issue, you close the PR, I can't even see it

I close the issue, you close the PR, I can't even see it
deloptes closed this issue 2 months ago
Owner
PR TDE/tde-packaging#109 closed.
Owner

I finally found the cause of the FTBFS that is reported in this issue!

Default Make rules include, among other things, the rules for generate *.l => *.c and *.y => *.c. If lexer.l or parser.y are newer data than lexer.c or parser.c contained in the source tree, this ensures that lex or yacc are automatically called to generate a new *.c files. And this causes FTBFS to occur. For testing, it is a simple procedure => do touch lexer.l or touch parser.y and start the build.

At the same time, it turned out that solutions proposed by Michele a long time ago (see comment and link to ML above) was absolutely correct. I prepare a PR that includes the proposed patch and also solves some other problems. See the links below.

I finally found the cause of the FTBFS that is reported in this issue! Default Make rules include, among other things, the rules for generate `*.l` => `*.c` and `*.y` => `*.c`. If `lexer.l` or `parser.y` are newer data than `lexer.c` or `parser.c` contained in the source tree, this ensures that `lex` or `yacc` are automatically called to generate a new `*.c` files. And this causes FTBFS to occur. For testing, it is a simple procedure => do `touch lexer.l` or `touch parser.y` and start the build. At the same time, it turned out that solutions proposed by Michele a long time ago (see comment and link to ML above) was absolutely correct. I prepare a PR that includes the proposed patch and also solves some other problems. See the links below.
SlavekB reopened this issue 2 weeks ago
SlavekB added a new dependency 2 weeks ago
Owner

The problem is finally resolved.

The problem is finally resolved.
SlavekB closed this issue 2 weeks ago
SlavekB added this to the R14.0.12 release milestone 2 weeks ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Loading…
There is no content yet.