Activity for Ludwin Janvier
-
Ludwin Janvier posted a comment on ticket #331
Yes, I backported code from trunk to GC2.2, and building is fine so far.
-
Sorry I was working on an older version. I didn't notice that this issue was fixed in trunk.
-
build logs 2
-
build logs 1
-
build fails randomly
-
I did it! Packages for 3.0 are here: https://launchpad.net/~lud-janvier/+archive/ubuntu/gnucobol-unstable (for Ubuntu 18.04 Bionic only) comments welcome
-
configuration directory can't be modified [patch]
-
No you're not. You have to: sudo dpkg --add-architecture i386 sudo apt-get update sudo apt-get install libcob4-dev:i386 Newer releases of Debian/Ubuntu are not multiarch (i386/amd64) anymore, so I don't think 32b should be required on 64b packages.
-
I'm not sure to understand. If you want to build a x86 binary, the easiest way is to add '-m32' to gcc (even if it's 64b)
-
Done (#528)
-
support for -g option in CFLAGS [patch]
-
Hi, I'd prefer to answer to these questions by mail. Could you send me your mail addr by private message?
-
Hi Simon, Speaking of GCC, Debian need the binaries to be build with '-g' option (in order to build debug packages too). From ./configure --help, the --enable-debug is meant for that. But this option disables all optimisations (-O0) I tried CFLAGS=-g ./configure but a sed in configure:18415 removes it (why?) Any hint?
-
Did you try with 'xenial' as distro name in the PPA conf ? It could work
-
My PPA doesn't contain binaries for cosmic, so this is a pretty normal error. You should remove my PPA from this system. If you're running cosmic, you should install gnucobol using default canonical repos (albeit I didn't test myself).
-
which distro/release do you run?
-
Hi Mickey, gnucobol will be in the next version of Ubuntu (cosmic cuttlefish). This means that if you're on the LTS channel, you will have to wait 2 years for Ubuntu's official gnucobol packages... Feel free to use my PPA at: https://launchpad.net/~lud-janvier/+archive/ubuntu/gnucobol Where you will find packages for Xenial and Bionic. As I'm actually the maintainer for Debian and Ubuntu, there will be only little difference beetween my packages and the distro's packages.
-
Hi Simon, I asked Debian guys about the non-reproducible issue. Here's their answer: https://lists.debian.org/debian-mentors/2018/06/msg00082.html It would be great if you could remove this files (doc/gnucobol.pdf and doc/gnucobol.info). Maybe in the next versions ?
-
I think it's the same issue I mentionned above with the PDF file GnuCOBOL comes with a doc/gnucobol.info that make clean removes
-
Hi, GnuCOBOL is now officialy available in Debian (testing)! https://packages.debian.org/buster/gnucobol
-
Not yet. It takes more time than I expected.
-
Your (last) point was the copyright file. The new one (attached) passes syntax checks. Could you validate it?
-
Actually you don't have to recompile any COBOL binary because they should run fine after update. You will have both libcob1 & libcob4 installed and updating to gnucobol won't remove libcob1 or conflict with it. Some packages manager such as aptitude would propose to clean libcob1. In this case, the system admin have to mark it as "manualy installed" and that's it!
-
Hi Simon, I can confirm what Brian suggested: Debian's libncurses5 package does not provides a libncurses.so, only libncurses5-dev does. You said earlier that the translations included are only "en", [...] Every gnucobol package in my ppa contains .mo files from the 2.2 release. And as far as I can test, it works: LANGUAGE=de cobc -a cobc: Unbekannte Option »-a« Isn't this the expected result?
-
That won't be the last ;-) run: instead of libdb-dev, libncurses5-dev only libdb and libncurses5 are needed (no dev parts for these, runtime is enough; dev for gmp is still needed; not sure about libltdl3-dev) For the records, libncurses5-dev is mandatory: cobc test.cbl /usr/bin/ld: cannot find -lncurses collect2: error: ld returned 1 exit status And I removed libltdl/libtool dependencies because README says it's not needed on Linux
-
Hi Simon, not sure but the "docs" file may or may not reference the (normally) installed manual found in doc/gnucobol.pdf There is a doc/gnucobol.pdf in the archive, but it is removed by make clean (which is the first step of the debian package build process) and the make default target does not rebuilt it. I may add make pdf manually in the process, but it's not a clean solution. Either : make clean does not remove the pdf make build the pdf (in this case, there's no need for it to be in the original...
-
Hi Simon, not sure but the "docs" file may or may not reference the (normally) installed manual found in doc/gnucobol.pdf There is a doc/gnucobol.pdf in the archive, but it is removed by make clean (which is the first step of the debian package build process) and the make default target does not rebuilt it. I may add make pdf manually in the process, but it's not a clean solution. Either : make clean does not remove the pdf make build the pdf (in this case, there's no need for it to be in the original...
-
Hi Simon, Thank you for your comments, I'm working on this issues. Here's my comments: please change the label from "GNUcobol" to "GnuCOBOL" Only the PPA name has this typo, not the package itself? include gnucobol_2.2.orig.tar.xz instead of getting it. My understanding of this page: https://www.debian.org/doc/manuals/maint-guide/upload.en.html#option-sa is that debian build systems don't download the orig, the maintener uploads it. But I don't know a lot about debian packages. configure completely...
-
Yes. The open-cobol package will remain (for some time), but will be a dummy package which depends on gnucobol package. A simple apt dist-upgrade replaces binaries from open-cobol by those from gnucobol Although, libcob1 and libcob1-dev will be replaced by libcob and a libcob-dev (no transition package here). I though there's no need for a libcob2/libcob3 package, correct me if I'm wrong.
-
Hi, I made packages for ubuntu and debian. You can find them here: https://launchpad.net/~lud-janvier/+archive/ubuntu/gnucobol (There are binaries and source) I will propose them to the main debian repo. Any comments are welcome, Ludwin PS: sorry I previously post it anonymously by error
-
changing --datarootdir would move the "copy" dir, which is at the right place :-) From configure --help, the --sysconfdir is meant for that, but this option has currently not effect. What about something like : if sysconfdir option cob_config_dir = $sysconfdir/gnucobol else cob_config_dir = no change fi ? May apply for Linux only
-
The package is currently waiting to build on canonical servers and will we available on launchpad.net soon. The COB_CONFIG_DIR is set to /usr/share/gnucobol/config I think this is not compliant with the Filesystem Hierarchy Standard (FHS). This should be set to /etc/gnucobol on Linux What would be the consequences? Would you accept a patch?
-
Of course. make checkall gives the same results
-
This patch will make configure[.ac] compliants with the -fstack-protector-strong option: --- configure.ac.old 2018-01-23 18:32:58.508000000 +0100 +++ configure.ac 2018-01-23 18:28:17.268000000 +0100 @@ -1140,6 +1140,7 @@ cob_temp_flags=`echo "$cob_temp_flags" | sed -e 's/-O//' -e 's/ $//' -e 's/^ //'` cob_temp_flags=`echo "$cob_temp_flags" | sed -e 's/-fmessage-length=0//'` cob_temp_flags=`echo "$cob_temp_flags" | sed -e 's/-D_FORTIFY_SOURCE=.//'` + cob_temp_flags=`echo "$cob_temp_flags" | sed -e...
-
I have another issue with the 'tests' or 'extras' directory which prevents me to build the whole project. I have a weird error when using the "-fstack-protector-strong" in the CFLAGS: export CFLAGS='-O2 -fstack-protector-strong' ./configure && make ... . ../tests/atconfig && . ../tests/atlocal extras-CBL_OC_DUMP.so \ && $COBC -m -Wall -O -o CBL_OC_DUMP.so CBL_OC_DUMP.cob gcc: error: unrecognized command line option '-strong' This flag is added by default by the debian/ubuntu package builders [1]....
-
Thanks for the help turns out that debian helper automaticly starts auto tests. Sorry for this question
-
Hi, I'd like to build a debian/ubuntu package for gnucobol, which may be publicly available (ppa?). The default make target (all) downloads a test suite and perfoms a lot of tests. Is there a simple way to build the binaries without performing this tests ? (configure option? make target?) Thanks in advance, Ludwin
-
defaults.list makes debian pkg not installable
1
