ZBar in Debian buster - Githubissues

jasp00 commented 5 years ago

I would like to invite @bzed to get involved in our Debian packaging, which is based on the official one. We have continuous integration builds for Debian sid.

We should consider whether current version of ZBar could be included in Debian buster. Looking at buster freeze policy, I think it is feasible. We can discuss details if you are interested.

bzed commented 5 years ago

First: great to see that somebody is working on zbar again. Thanks!

For buster changes may not break the libzbar APi+ABI. The time for transitions is gone. Other changes are not a problem, but we need to be really quick.

jasp00 commented 5 years ago

The only changes are in libzbarqt0, which does not seem to have reverse dependencies. My idea is that you package a first snapshot of master, unless we create stable. Then we would fix possible bugs for a month and release. @mchehab, is it fine?

jasp00 commented 5 years ago

Bad news. We change the API for zbar_version().

mchehab commented 5 years ago

Bad news. We change the API for zbar_version().

True, we added support there on version 0.20 for ZBar to report (major, minor, patch), in order for Zbar to use the standard https://semver.org/ spec. The goal is to avoid increasing the minor version with just bugfixes. I guess it shouldn't be a problem to add a patch at Zbar debian buster package to partially revert the changeset, making zbar_version() not reporting the patch anymore. We could, instead, revert to the old ABI, and place defines for ZBARVERSION* at the header, in a way that new programs would use the defines instead of calling a function in order to get (major, minor, patch) tuple.

mchehab commented 5 years ago

The only changes are in libzbarqt0, which does not seem to have reverse dependencies.

Afaikt, this is used only at zbarcam-qt, with is part of the ZBar package. So, it shouldn't be a problem.

My idea is that you package a first snapshot of master, unless we create stable. Then we would fix possible bugs for a month and release. @mchehab, is it fine?

Yes, sure. Btw, Fedora has been using the new ZBar code since Fedora 25. I've been maintaining ZBar package there. There are no other package shipped there with depends on ZBar - and Fedora development cycle is 6 months - with makes a little easier to change the API/ABI, but still we need to take care of properly handling changes that might affect it.

mchehab commented 5 years ago

Forgot to mention, but I'm OK on creating a stable branch.

jasp00 commented 5 years ago

In Debian sid, gstreamer1.0-plugins-bad, libvisp-detection3.1, and shadowsocks-qt5 depend on libzbar0. Neither source package depends on zbar_version(), so there should not be any break. We could go on.

@bzed, I would like to discuss whether new binary packages could be added. Freeze policy says "no new packages", but I understand this means no new source packages. zbarcam-gtk and zbarcam-qt should be in their own packages to avoid Qt and GTK dependencies. Java files should be in libzbar-java. What do you think?

bzed commented 5 years ago

New packages have to go trough the new queue, chances that will happen before the freeze are really low.

jasp00 commented 5 years ago

@mchehab, could you create stable now?

@bzed, please package a first snapshot of stable.

@epozuelo, we are trying to release a new version of ZBar for buster. We would fix possible bugs in our stable branch for a month. Could we include the Java library in a new libzbar-java package? It does not make sense to include it in an existing package.

mchehab commented 5 years ago

I created a stable-.0.21 branch and a tag: 0.21-rc1. I also uploaded the tarball for -rc1 to: https://linuxtv.org/downloads/zbar/ My plan is to launch 0.21 final next week, if nothing weird happens.

jasp00 commented 5 years ago

Hi, @hosiet. I see that you have uploaded version 0.10+doc-11 today. Could you explain this to us? Has bzed orphaned the package now? Could you integrate your changes in the stable-0.21 branch?

hosiet commented 5 years ago

Hi @jasp00 ,

I didn't know this repository at all before you mentioned me here today.

I believe zbar is literally orphaned in Debian and no one is acting as the maintainer right now. I didn't know @bzed before but if he is going to help to improve zbar in Debian, it would be really great and I think we could cooperate together (as Debian Developers).

My upload today was merely a clean-up upload based on the old codebase. Besides, I dropped the qt library as part of the efforts to eliminate Qt4-related stuff in Debian. If there's going to be another zbar release with no ABI/API breakage, we should act really fast to evaluate and upload the new version of zbar ASAP.

P.S., for the qt library, I do not intend to reintroduce it unless it has been migrated onto Qt5. Could anyone tell me the status of qt-based stuff in zbar right now?

jasp00 commented 5 years ago

We support both Qt 4 and Qt 5. Continuous integration builds use Qt 5.

Please coordinate with @bzed, integrate your changes, and package a snapshot of stable-0.21 in order to get more testing.

bzed commented 5 years ago

Hi, @hosiet. I see that you have uploaded version 0.10+doc-11 today. Could you explain this to us? Has bzed orphaned the package now? Could you integrate your changes in the stable-0.21 branch?

I've orphaned zbar almost a year ago. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898078

bzed commented 5 years ago

As there is some active development now, I wouldn't mind to sponsor uploads at least, but I would prefer if somebody else could handle it as I don't use zabr anymore.. So @hosiet - if you would like to take over the maintenance, that would be great.

mchehab commented 5 years ago

Hi @jasp00 ,

My upload today was merely a clean-up upload based on the old codebase. Besides, I dropped the qt library as part of the efforts to eliminate Qt4-related stuff in Debian.

I migrated it to support Qt5 in 2017. We've shipping it with Qt5 on Fedora since April, 2017. It can still be compiled against Qt4, if anyone wants it, but I don't even test backward compat with it.

If there's going to be another zbar release with no ABI/API breakage, we should act really fast to evaluate and upload the new version of zbar ASAP.

There are no plans to do any ABI/API breakage. We are right now on a release candidate for version 0.21. I opted to not release version 0.21 yet because we had lots of improvements added and I wanted to have some time to run some stress tests.

One thing that was bothering me is that test/test_decode was failing. This test produces some 1D barcodes for different symbologies, add noise and tries to decode. Well, when running to produce and decode 100 k random interactions, it was aborting due to an error. So, I looked at the tests there, improving the test code and its output, in order to better understand what kind of troubles it is detecting.

After the changes, I ran a long test (10 million interactions) during this weekend. It turns that about 0.0029% of the produced images could be detected by multiple decoders (basically, EAN-2 mis-detected some Codabar codes), and about 0.0043% of the produced images could be too noisy to be decoded. There was not a single case where a barcode was decoded with a wrong value.

That sounded pretty good to my eyes. So, from my side, I'm happy with the current status, but it won't hurt to wait a couple of days to release 0.21 final.

In any case, between version 0.21-rc1 and 0.21 final, I would expect only bug fixes and perhaps support for inverted QR code images (PR #22).

hosiet commented 5 years ago

Hi all,

I've just prepared an upload onto Debian Experimental with some major rewrite on Debian's build scripts. You may view the packaging file tree here: https://salsa.debian.org/debian/zbar/tree/10f1aba430d33df16edc1a2d0c4524d3f47ba7d7

Let's see how Debian's automatic build system takes this package. If everything goes on well, I will push it down and make sure the package gets into Debian Buster.

bzed commented 5 years ago

Hi,

I've added a debian/.gitlab-ci.yml file to the experimental branch on salsa and configured the repository accordingly.

First pipeline is running: https://salsa.debian.org/debian/zbar/pipelines/36482

Much faster than waiting for buildds :)

Enjoy,

Bernd

bzed commented 5 years ago

@hosiet please push the pristine-tar branch!

hosiet commented 5 years ago

Looks like all Debian Salsa CI tests have passed. Will upload onto Debian Unstable then.

mchehab commented 5 years ago

You should probably consider zbar 0.22 for Sid. I'm updating it for Fedora rawhide.

The main focus of this version is to make zbarcam-qt a full-featured application, allowing to use all ZBar library features with a GUI interface.

It also comes with an optional new feature to allow inverting the colors when parsing images. That's specially useful for QR codes, as it seems that several such barcodes come inverted.

There are also some bug fixes on it.

Sumary of changes:

zbarcam-qt: allow changing resolutions in real time
zbarcam-qt: better support ZBar options
zbarcam-qt: do several visual improvements
zbarcam-qt: make it remember the geometry
zbarcam-qt: allow show/hide control and options bars
zbarcam-qt: remember lastly used settings and camera controls
zbarcam-qt: allow changing ZBar decode options via GUI
Add API to allow get/set resolutions
img_scanner: add handler for color-inverted codes
img_scanner: fix get_config parameter validation
scan_video: improve logic to remove duplicated/invalid devnodes
symbol.c: fix symbol hash logic (prevents crash with QR options)
configure.ac: fix an error at libv4l2 package check
fix some typos
exit gracefully when decoding split QR codes

hosiet commented 5 years ago

@mchehab It's okay if we update zbar in Debian to 0.22. However the Buster freeze deadline is really approaching and I think we have no time to reintroduce Qt5-related parts back into Debian.

mchehab commented 5 years ago

@mchehab It's okay if we update zbar in Debian to 0.22. However the Buster freeze deadline is really approaching and I think we have no time to reintroduce Qt5-related parts back into Debian.

AFAIKT, the libzbarcam-qt was never used by any external application, but, if this is a problem, one possible solution would be to build zbarcam-qt with a static qt5 library. It should probably be easy to add a patch to the building system in order to allow such kind of build.

hosiet commented 5 years ago

Introducing static qt5 library into distributions is even harder than pushing zbarcam-qt (qt5 version) into Debian (due to Debian's policies). I'd rather leave that work to end users.

mchehab commented 5 years ago

Introducing static qt5 library into distributions is even harder than pushing zbarcam-qt (qt5 version) into Debian (due to Debian's policies). I'd rather leave that work to end users.

You won't need to ship the static library. Just build zbarcam-qt with it, in order to avoid a dynamic dependency.

hosiet commented 5 years ago

That's already exactly what I was talking about; it will be detected by Debian's CI system and lead to critical bugs and/or autorejection. :-(

mchehab commented 5 years ago

That's already exactly what I was talking about; it will be detected by Debian's CI system and lead to critical bugs and/or autorejection. :-(

Not sure how Debian packaging works. On Fedora, when we want to do something like that, we add a rm <file> at the end of the build rule for files that that won't be packaged, as otherwise Fedora building system would produce an error.

Anyway, it is actually your call.

Personally, I never use the "zbarcam" app myself... it is too hard to use it, as it requires opening a separate app in order to make the camera to produce a good enough image to be parsed by ZBar.

If you opt to ship with zbarcam-qt, but without libzbar-qt.so, this commit adds a new --enable-static-qt option, with makes zbarcam-qt of not depending on the dynamic qt5 library anymore: https://github.com/mchehab/zbar/commit/f6699ebb52e92b1c7efbd87d4f0422844c472135.

mchehab commented 5 years ago

Not sure how Debian packaging works. On Fedora, when we want to do something like that, we add a rm at the end of the build rule for files that that won't be packaged, as otherwise Fedora building system would produce an error.

Out of curiosity, I double checked the Fedora's zbar.spec file. The install rule there is:

%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"

#Remove .la and .a files
find ${RPM_BUILD_ROOT} -name '*.la' -or -name '*.a' | xargs rm -f

# Remove installed doc
rm -rf $RPM_BUILD_ROOT/usr/share/doc/zbar-%{version}/

Basically, it only keeps the produced man files, removing the html ones and any static libraries that might eventually be built.

So, if we ever decide to not ship libzbarqt.so there, the script would already do the right thing.

mchehab commented 5 years ago

@jasp00 @hosiet @bzed : what's the status of this issue? It seems that buster is already with zbar-0.22.1:

https://packages.debian.org/source/buster/zbar

So, can we close this issue?

jasp00 commented 5 years ago

A recent version of ZBar is included in Debian buster.

mchehab / zbar

ZBar in Debian buster #15