Description of problem: The libosmocore's and libosmodsp's pc files contain a wrong Version tag $grep UNKNOWN /usr/lib64/pkgconfig/* /usr/lib64/pkgconfig/libosmocodec.pc:Version: UNKNOWN /usr/lib64/pkgconfig/libosmocore.pc:Version: UNKNOWN /usr/lib64/pkgconfig/libosmoctrl.pc:Version: UNKNOWN /usr/lib64/pkgconfig/libosmodsp.pc:Version: UNKNOWN /usr/lib64/pkgconfig/libosmogb.pc:Version: UNKNOWN /usr/lib64/pkgconfig/libosmogsm.pc:Version: UNKNOWN /usr/lib64/pkgconfig/libosmovty.pc:Version: UNKNOWN Version-Release number of selected component (if applicable): libosmocore-0.9.6-5.20170220git32ee5af8.fc28.x86_64 libosmo-dsp-devel-0.3-7.fc28.x86_64 Actual results: $ pkg-config --modversion libosmocore UNKNOWN $ pkg-config --modversion libosmodsp UNKNOWN Expected results: $ pkg-config --modversion libosmocore 0.9.6-5.20170220git32ee5af8 $ pkg-config --modversion libosmodsp 0.3-7 Additional info: A possible solution is to add the following command in the spec file in the %build section test -x ./git-version-gen && echo %{version}-%{release} > .tarball-version 2>/dev/null https://osmocom.org/issues/3449 https://gerrit.osmocom.org/c/osmo-ci/+/10343
Thanks, applied.
libosmocore-0.9.6-9.20170220git32ee5af8.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e0c7e8678c
libosmocore-0.9.6-9.20170220git32ee5af8.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-73ef94412f
libosmocore-0.9.6-9.20170220git32ee5af8.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-3863a19e6f
(In reply to Jaroslav Škarvada from comment #1) > Thanks, applied. Thanks. Should I open a separate bug for libosmo-dsp package as it has the same problem? BTW the URL in libosmocore is not correct URL: http://sdr.osmocom.org/trac/wiki/GrOsmoSDR probably it should be URL: https://osmocom.org/projects/libosmocore
libosmocore-0.9.6-9.20170220git32ee5af8.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e0c7e8678c
libosmocore-0.9.6-9.20170220git32ee5af8.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-3863a19e6f
libosmocore-0.9.6-9.20170220git32ee5af8.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-73ef94412f
(In reply to Vasil Velichkov from comment #5) > (In reply to Jaroslav Škarvada from comment #1) > > Thanks, applied. > > Thanks. Should I open a separate bug for libosmo-dsp package as it has the > same problem? > It isn't needed, I will fix it. But please bring the problem upstream (if not yet fixed). > BTW the URL in libosmocore is not correct > > URL: http://sdr.osmocom.org/trac/wiki/GrOsmoSDR > > probably it should be > > URL: https://osmocom.org/projects/libosmocore Fixed in rawhide, thanks.
> But please bring the problem upstream (if not yet fixed). If you know could you tell me where the libosmocore-0.9.6-20170220git32ee5af8.tar.bz2 has been downloaded from, or how it has been created. If I understand correctly the release tarballs are expected to contains the .tarball-version file which is generated by running `make dist` but right now I can't find where such release tarballs could be downloaded from.
(In reply to Vasil Velichkov from comment #10) > > But please bring the problem upstream (if not yet fixed). > > If you know could you tell me where the > libosmocore-0.9.6-20170220git32ee5af8.tar.bz2 has been downloaded from, or > how it has been created. If I understand correctly the release tarballs are > expected to contains the .tarball-version file which is generated by running > `make dist` but right now I can't find where such release tarballs could be > downloaded from. I meant libosmo-dsp (http://cgit.osmocom.org/libosmo-dsp/), the libosmocore should be already fixed upstream. But no problem, I will check.
(In reply to Jaroslav Škarvada from comment #11) > (In reply to Vasil Velichkov from comment #10) > > > But please bring the problem upstream (if not yet fixed). > > > > If you know could you tell me where the > > libosmocore-0.9.6-20170220git32ee5af8.tar.bz2 has been downloaded from, or > > how it has been created. If I understand correctly the release tarballs are > > expected to contains the .tarball-version file which is generated by running > > `make dist` but right now I can't find where such release tarballs could be > > downloaded from. > > I meant libosmo-dsp (http://cgit.osmocom.org/libosmo-dsp/), the libosmocore > should be already fixed upstream. But no problem, I will check. No, it's not, see http://cgit.osmocom.org/libosmocore/tree/configure.ac?h=master#n2 And that's why I've asked where do you get the source tarballs from and do you build them with make distcheck of just upload what you've downloaded.
I opened: https://osmocom.org/issues/3868 I didn't run 'make distcheck'. Regarding the libosmo-dsp, it should be stable release.
libosmocore-0.9.6-9.20170220git32ee5af8.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
libosmocore-0.9.6-9.20170220git32ee5af8.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
libosmocore-0.9.6-9.20170220git32ee5af8.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.