#147 Debian build fails
As per my post on the mailing list I have been trying to build a deb for v2.6.3
These are my notes as I went along.
I finally figured out how to build 2.6.0 - the build wants:
"dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../zint_2.6.0.orig.tar.{bz2,gz,lzma,xz}"
"zint_2.6.0.orig.tar.gz" but the download is "zint-2.6.0.src.tar.gz"
(Damned if I can find where this is set in the source - it was easier to rename the source file)
So:
wget https://sourceforge.net/projects/zint/files/zint/2.6.0/zint-2.6.0.src.tar.gz -O zint_2.6.0.orig.tar.gz
tar -zxvf zint_2.6.0.orig.tar.gz
cd zint-2.6.0
dpkg-buildpackage -us -uc
This builds:
zint_2.6.0_amd64.deb
zint-qt_2.6.0_amd64.deb
OK,
Trying the same sort of thing with 2.6.3
tar -zxvf zint-2.6.3_final.tar.gz
This gives us zint-2.6.3.src (inconsistent dir name compared to 2.6.0)
cd zint-2.6.3.src
dpkg-buildpackage -us -uc
dpkg-buildpackage: source package zint
dpkg-buildpackage: source version 2.6.0
dpkg-buildpackage: source distribution stable
dpkg-buildpackage: source changed by Robin Stuart rstuart114@gmail.com
dpkg-buildpackage: host architecture amd64
dpkg-source --before-build zint-2.6.3.src
fakeroot debian/rules clean
dh clean
dh_testdir
dh_auto_clean
dh_clean
dpkg-source -b zint-2.6.3.src
dpkg-source: warning: non-native package version does not contain a
revision dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building zint using existing ./zint_2.6.0.orig.tar.gz
Finally found that I needed to edit the debian/changelog to get it to work. That sorts out where the 'version' number comes from though I don't see where it picks up the 'orig' part from.
The whole changelog could do with being updated properly as there is lots of version missing, and it requires the latest version added to be able to build correctly.
Once I added a 2.6.3 entry it then built these.
zint_2.6.3_amd64.deb
zint-qt_2.6.3_amd64.deb
The only think I can't figure how to do is add the .desktop to the deb file automatically.
Ironically I can see the conf in the RPM spec file but nothing in the Debian dir. I can also see some mimelink stuff as well for when you do a straight build with 'make install' but not in the debian dir
And last but not least....
Installing zint as a deb sems to depend on libpng12-dev ??
And zint-qt depends on libqt4-dev ?
Removed those and it builds fine so I think you can patch with this (if the project was on github I'd try and submit a PR)
I can not help here, sorry. May this be closed ?
Thank you,
Harald
I did post this bug on the list, to be told to post here, and now to be told it can't be fixed?
It is a bug - more than one - and I even provided a couple of diffs for part of it. It would work perfectly with a few small mods and the source code being named correctly.
There's no hope is there?
It should be left open if it is not going to be fixed. A reminder to everyone else not to try and help fix things.
Sorry.
Please verify, if 2.6.4 suites your need.
I must admit, that I did not find out what was ment in the post.
Thank you,
Harald
Hi,
Trying to build debian packages from freshly downloaded 2.7.0 sources, here are issues I faced:
First, changelog file is not up to date as v2.7.0 entry is missing
Then, simple
dpkg-buildpackage -us -ucfailed with "no upstream tarball" error. Solved usingdpkg-buildpackage -b -rfakeroot -us -uc.Then, solved libpng12-dev dependency replacing it by libpng-dev
Then installed needed
qtbase5-devandqttools5-devmissing from build dependencies.But finally failed with:
Building CXX object frontend_qt/CMakeFiles/zint-qt.dir/mainwindow.cpp.o cd /home/tarax/Downloads/zint-2.7.0/obj-x86_64-linux-gnu/frontend_qt && /usr/bin/c++ -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_UITOOLS_LIB -DQT_WIDGETS_LIB -DZINT_VERSION=\"2.6.7\" -I/home/tarax/Downloads/zint-2.7.0/obj-x86_64-linux-gnu/frontend_qt -I/home/tarax/Downloads/zint-2.7.0/frontend_qt -I/home/tarax/Downloads/zint-2.7.0/backend_qt -I/home/tarax/Downloads/zint-2.7.0/backend -I/home/tarax/Downloads/zint-2.7.0 -I/home/tarax/Downloads/zint-2.7.0/obj-x86_64-linux-gnu -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem /usr/include/x86_64-linux-gnu/qt5/QtUiTools -g -O2 -fdebug-prefix-map=/home/tarax/Downloads/zint-2.7.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wall -fPIC -o CMakeFiles/zint-qt.dir/mainwindow.cpp.o -c /home/tarax/Downloads/zint-2.7.0/frontend_qt/mainwindow.cpp /home/tarax/Downloads/zint-2.7.0/frontend_qt/mainwindow.cpp: In constructor ‘MainWindow::MainWindow(QWidget*, Qt::WindowFlags)’: /home/tarax/Downloads/zint-2.7.0/frontend_qt/mainwindow.cpp:161:13: error: ‘chkAutoHeight’ was not declared in this scope 161 | connect(chkAutoHeight, SIGNAL(stateChanged( int )), SLOT(autoheight_clicked())); | ^~~~~~~~~~~~~ /home/tarax/Downloads/zint-2.7.0/frontend_qt/mainwindow.cpp: In member function ‘void MainWindow::autoheight_clicked()’: /home/tarax/Downloads/zint-2.7.0/frontend_qt/mainwindow.cpp:331:9: error: ‘chkAutoHeight’ was not declared in this scope 331 | if (chkAutoHeight->isChecked()) { | ^~~~~~~~~~~~~ /home/tarax/Downloads/zint-2.7.0/frontend_qt/mainwindow.cpp:332:9: error: ‘lblHeight’ was not declared in this scope; did you mean ‘PdmHeight’? 332 | lblHeight->setEnabled(false); | ^~~~~~~~~ | PdmHeight /home/tarax/Downloads/zint-2.7.0/frontend_qt/mainwindow.cpp:335:9: error: ‘lblHeight’ was not declared in this scope; did you mean ‘PdmHeight’? 335 | lblHeight->setEnabled(true); | ^~~~~~~~~ | PdmHeight /home/tarax/Downloads/zint-2.7.0/frontend_qt/mainwindow.cpp: In member function ‘void MainWindow::update_preview()’: /home/tarax/Downloads/zint-2.7.0/frontend_qt/mainwindow.cpp:1072:8: error: ‘chkAutoHeight’ was not declared in this scope 1072 | if(chkAutoHeight->isChecked()) { | ^~~~~~~~~~~~~ make[3]: *** [frontend_qt/CMakeFiles/zint-qt.dir/build.make:154: frontend_qt/CMakeFiles/zint-qt.dir/mainwindow.cpp.o] Error 1 make[3] : on quitte le répertoire « /home/tarax/Downloads/zint-2.7.0/obj-x86_64-linux-gnu » make[2]: *** [CMakeFiles/Makefile2:279: frontend_qt/CMakeFiles/zint-qt.dir/all] Error 2 make[2] : on quitte le répertoire « /home/tarax/Downloads/zint-2.7.0/obj-x86_64-linux-gnu » make[1]: *** [Makefile:133: all] Error 2 make[1] : on quitte le répertoire « /home/tarax/Downloads/zint-2.7.0/obj-x86_64-linux-gnu » dh_auto_build: cd obj-x86_64-linux-gnu && make -j1 returned exit code 2 make: *** [debian/rules:3: build] Error 255 dpkg-buildpackage: erreur: debian/rules build subprocess returned exit status 2Thank you in advance for your support
Jeremie
Last edit: silopolis 2019-12-23
Given the age of this ticket, am closing now. Please open a new ticket for issues with Debian builds on more modern zint releases, thanks.
A follow up to this.
Adding this for reference as no point in a new bug as it will be a wontfix.
Same issues as the debian directory is way out of date.
I just built 2.15 from Debian sources on a buntu 24.04 box
Seems to work OK.
Tried a similar trick using the zint source for 2.16 and the debian 2.15 files but that failed. Seems to build the zint files & libraries but fails at building other bits and the packages.
Guess there are some makefile discrepancies that Debian fixes in their release.
Trying to fix it is way beyond my paygrade.
Hi John, re-opening this. Yes the debian stuff is way out of date. I've never looked at it myself and never used dpkg-buildpackage. But am interested in getting it to work and this won't be a wontfix. However it will be a few days before I can look at it.
Thank you for taking the time and effort to respond here, and for raising the issue in the first place, your feedback is genuinely much appreciated, best regards, Martin
Ah cool!! Thanks Martin.
I would suggest a look at their package stuff as it clearly worked on 2.15 as described above. I essentially just removed your old debian build stuff and added theirs (I am no guru at this build stuff!)
I kind of followed from here:
https://packages.debian.org/search?keywords=zint&searchon=names&suite=testing§ion=all
Might be worth keeping in contact with the maintainers there who would probably help.
Mnay thanks, John
Hi John, eventually got something that "works for me" with commit [df64a0]. Added a "README.deb" which might be useful.
The cmake issue was down to a change to accommodate Nix (commit [9265ab] last year).
Thanks for the pointers, had to do a lot of reading to work it out. There's still some issues, e.g. support for the GS1 Syntax Engine isn't enabled. I haven't contacted the maintainers yet (though I copied a lot of their stuff), but may do in future.
It also prompted an audit of copyrights which lead to the discovery of some probable violations of the BSD-3-Clause licence that applies to the library, in particular the use of "libtiff"'s LZW implementation (fixed), and the adaption from a long time ago of some GPL2.0-or-later stuff in the PDF417 code (not fixed yet).
So a very worthwhile exercise.
If you could try it out that would be great.
All the best, Martin
Related
Commit: [9265ab]
Commit: [df64a0]
Hi - just dropping in to see if I can fix that PDF417 problem. My fault - I should have sorted that out years ago! There is no code from Grandzebu's project in Zint so I'm confident his copyright can be removed. When the header says it was "adapted from" his code that is, in retrospect, incorrect. Today I would say it was "inspired by" his code - the algorithm started off being the same but the code was completely re-written. The only thing that remains is some of the variable names. I think the line-number references to his VB code can also be removed as I'm sure they have not been used by anyone for many years. Grandzebu has never submitted code to Zint and I have never communicated with him.
The only portions which were directly copied from Grandzebu were tables which are now in pdf417_tabs.h. More specifically they are:
zint_pdf_coefrs which is still almost identical what Grandzebu has, but which is also just a transcription from the ISO standard, so I'm not sure Grandzebu can actually claim copyright over the contents of this table. For that matter I'm not sure I can either.
zint_pdf_bitpattern which was originally calculated from Grandzebu's code (which was formatted in a way compatible with his own font) but, I would argue, has been substantially changed and now similarly only serves as a representation of the tables originally taken from the ISO standard.
Grandzebu's code was used because I did not, at the time, have access to the ISO standard. A short time after I got access to the ISO standard I went through both of these tables and checked all of the values - and I remember finding at least one error in zint_pdf_bitpattern - so I think I could argue that they are now copied from the ISO standard rather than from Grandzebu. At the time, however, I didn't think to remove references to Grandzebu in the copyright section - and so he is still there.
I should state here - just in case Grandzebu reads this - that I although I'm pretty confident that his name can and should be removed from these files - I am also very grateful to him for writing that code and making it available online so many years ago - it really helped when I was trying to get this project started. On his website it says "there is nothing free on the net" for barcodes, which is not true any more but was absolutely true in 2008. The mention he gets in the manual should definitely stay!
I know, I know - you don't hear from me for ages then I just drop in and casually write a book! But just briefly - thank you Martin and Harald for the continuing great work on this project - your dedication and skill continues to amaze me - and thank you John for taking the time to submit a detailed ticket.
Robin.
Hi Robin, great to hear from you!
Re "pdf417_tab.h", yes, I noticed that the info is just transcriptions of the ISO/IEC standard and adjusted the comments accordingly (if not always correctly) in commit [df64a0] - however I forgot to remove the Copyright notices in "pdf417_tab.h" & "pdf417.h" - have rectified that (plus some fixes & expansion of the comments) with commit [a9eef1].
Interesting to hear about the evolution of the code, however looking at "pdf417.frm" and at the line numbers in "pdf417.c" I think there still are recognizable echoes of the original code there, remarkably enough, after all this time.
So I'm in two minds but am leaning towards rewriting those sections, reluctantly. However the mention of the great Grandzebu will definitely remain in the manual, and indeed in some form in the code.
As always delighted you "just dropped in" - and thank you for the thanks, appreciated.
All the best, Martin
Related
Commit: [a9eef1]
Commit: [df64a0]