GNOME Bugzilla – Bug 794252
meson: check version array length before accessing micro version
Last modified: 2018-03-13 08:11:11 UTC
In the Autotools build, the micro version used to be defined manually every release, but, after the Meson port, the micro version in the array is accessed unconditionally, which results in failures in stable releases, as the micro version is unset.
Created attachment 369566 [details] [review] meson: check version array length before accessing micro version
Review of attachment 369566 [details] [review]: LGTM
Review of attachment 369566 [details] [review]: We use `meson.project_version()` elsewhere in the build — like the pkg-config file. This means that `pkg-config --modversion atk` will return `2.28`, instead of `2.28.0`. The appropriate fix is to use `2.28.0` as the project version in the meson.build file, just like we do in the configure.ac file.
*** Bug 794254 has been marked as a duplicate of this bug. ***
(In reply to Emmanuele Bassi (:ebassi) from comment #4) > Review of attachment 369566 [details] [review] [review]: > > We use `meson.project_version()` elsewhere in the build — like the > pkg-config file. This means that `pkg-config --modversion atk` will return > `2.28`, instead of `2.28.0`. > > The appropriate fix is to use `2.28.0` as the project version in the > meson.build file, just like we do in the configure.ac file. Of course, now that ATK 2.28.0 has been released, we're going to need a 2.28.0.1 release, with a 2.28.0.1 version. Ideally, we should just get rid of the Autotools build, to avoid this kind of mess in the future. I guess this'll have to happen in the next development cycle.
Let’s go with the patch in bug 794254. (In reply to Emmanuele Bassi (:ebassi) from comment #6) > Of course, now that ATK 2.28.0 has been released, we're going to need a > 2.28.0.1 release, with a 2.28.0.1 version. How will that affect the binary age formula? Adding more zeroes to coefficients and appending the new version number?
(In reply to Ernestas Kulik from comment #7) > Let’s go with the patch in bug 794254. > > (In reply to Emmanuele Bassi (:ebassi) from comment #6) > > Of course, now that ATK 2.28.0 has been released, we're going to need a > > 2.28.0.1 release, with a 2.28.0.1 version. > > How will that affect the binary age formula? Adding more zeroes to > coefficients and appending the new version number? "Nano" versions are typically reserved for this kind of packaging snafu, and they don't contribute to things like the binary age and the soname definition.
(In reply to Emmanuele Bassi (:ebassi) from comment #6) > (In reply to Emmanuele Bassi (:ebassi) from comment #4) > > Review of attachment 369566 [details] [review] [review] [review]: > > > > We use `meson.project_version()` elsewhere in the build — like the > > pkg-config file. This means that `pkg-config --modversion atk` will return > > `2.28`, instead of `2.28.0`. > > > > The appropriate fix is to use `2.28.0` as the project version in the > > meson.build file, just like we do in the configure.ac file. > > Of course, now that ATK 2.28.0 has been released, we're going to need a > 2.28.0.1 release, with a 2.28.0.1 version. As mentioned on the other bug, yes, I will roll a new release later today. Will check if there is any new patch here, just in case. > Ideally, we should just get rid of the Autotools build, to avoid this kind > of mess in the future. I guess this'll have to happen in the next > development cycle. TL;DR: Yes, my plan was getting rid of autotools during this cycle, but unfourtunately I didn't have too much time to check it properly. I would really try to do that on the next cycle. Details: as I said, I didn't have too much time to check how to do releases with meson properly. For example, Im used to use make distcheck for the tarball, but there isn't a direct equivalent (AFAIK) on meson. I think that the idea is using git tag/git archive [1], but not sure, and didn't have time to ask/investigate. FWIW, if there is a "GNOME recipe" to do releases with meson, it would be awesome to update this recipe: https://wiki.gnome.org/MaintainersCorner/Releasing [1] https://blogs.gnome.org/mclasen/2017/04/20/meson-considerations/
`ninja dist` now does the same thing as `make distcheck`, but the Wiki page should be updated, indeed.
(In reply to Alejandro Piñeiro Iglesias (IRC: infapi00) from comment #9) > (In reply to Emmanuele Bassi (:ebassi) from comment #6) > > (In reply to Emmanuele Bassi (:ebassi) from comment #4) > > > Review of attachment 369566 [details] [review] [review] [review] [review]: > > > > > > We use `meson.project_version()` elsewhere in the build — like the > > > pkg-config file. This means that `pkg-config --modversion atk` will return > > > `2.28`, instead of `2.28.0`. > > > > > > The appropriate fix is to use `2.28.0` as the project version in the > > > meson.build file, just like we do in the configure.ac file. > > > > Of course, now that ATK 2.28.0 has been released, we're going to need a > > 2.28.0.1 release, with a 2.28.0.1 version. > > As mentioned on the other bug, yes, I will roll a new release later today. > Will check if there is any new patch here, just in case. Thanks. > > Ideally, we should just get rid of the Autotools build, to avoid this kind > > of mess in the future. I guess this'll have to happen in the next > > development cycle. > > TL;DR: Yes, my plan was getting rid of autotools during this cycle, but > unfourtunately I didn't have too much time to check it properly. I would > really try to do that on the next cycle. Also my fault: I should have helped, considering I landed the Meson build in the first place. > Details: as I said, I didn't have too much time to check how to do releases > with meson properly. For example, Im used to use make distcheck for the > tarball, but there isn't a direct equivalent (AFAIK) on meson. I think that > the idea is using git tag/git archive [1], but not sure, and didn't have > time to ask/investigate. With recent versions of Meson, you'll get a `dist` target automatically generated for the Ninja backend; you can simply do: ``` $ ninja -C _build dist ``` and you'll get a release tarball in `_build/meson-dist`. It contains everything inside the Git repo, and Meson will also run a check on it. The only difference is that the Meson-generated release archive will not contain the generated API reference; we're in the process of solving the issue for publishing the reference on developer.gnome.org, though. > FWIW, if there is a "GNOME recipe" to do releases > with meson, it would be awesome to update this recipe: > https://wiki.gnome.org/MaintainersCorner/Releasing Indeed, I'll make sure to update the wiki page.
Fixed in d5b7fa2376f3adbdc55f5cb579f068102a768f54.
(In reply to Ernestas Kulik from comment #12) > Fixed in d5b7fa2376f3adbdc55f5cb579f068102a768f54. Yes I made a first silly commit to fix master. Although I went ahead : (In reply to Emmanuele Bassi (:ebassi) from comment #11) > (In reply to Alejandro Piñeiro Iglesias (IRC: infapi00) from comment #9) > > (In reply to Emmanuele Bassi (:ebassi) from comment #6) > > > (In reply to Emmanuele Bassi (:ebassi) from comment #4) > > > > Review of attachment 369566 [details] [review] [review] [review] [review] [review]: > > > > > > > > We use `meson.project_version()` elsewhere in the build — like the > > > > pkg-config file. This means that `pkg-config --modversion atk` will return > > > > `2.28`, instead of `2.28.0`. > > > > > > > > The appropriate fix is to use `2.28.0` as the project version in the > > > > meson.build file, just like we do in the configure.ac file. > > > > > > Of course, now that ATK 2.28.0 has been released, we're going to need a > > > 2.28.0.1 release, with a 2.28.0.1 version. > > > > As mentioned on the other bug, yes, I will roll a new release later today. > > Will check if there is any new patch here, just in case. > > Thanks. In the end I did the new release today. I went directly for a 2.28.1 (vs 2.28.0.1) release even if was done just to fix this silly mistake. > > Details: as I said, I didn't have too much time to check how to do releases > > with meson properly. For example, Im used to use make distcheck for the > > tarball, but there isn't a direct equivalent (AFAIK) on meson. I think that > > the idea is using git tag/git archive [1], but not sure, and didn't have > > time to ask/investigate. > > With recent versions of Meson, you'll get a `dist` target automatically > generated for the Ninja backend; you can simply do: > > ``` > $ ninja -C _build dist > ``` > > and you'll get a release tarball in `_build/meson-dist`. It contains > everything inside the Git repo, and Meson will also run a check on it. The > only difference is that the Meson-generated release archive will not contain > the generated API reference; we're in the process of solving the issue for > publishing the reference on developer.gnome.org, though. Ok, thanks for the recipe. 2.28.1 was done using autotools, just to keep the documentation there. But I would really like to make "autotools purge" one of the first commits on the next release. Hopefully during next cycle the documentation issues would be solved. I will keep the bug opened just in case I made something wrong again.