app-office/planner: new live ebuild, fix 814152, 784086 in old ebuild

[Schievel1]

I prepared the 9999 ebuild to be used as a normal ebuild as well, once upstream has released a new version.

[gentoo-bot]

Pull Request assignment

Submitter: @Schievel1
Areas affected: ebuilds
Packages affected: app-office/planner

app-office/planner: @gentoo/gnome

Linked bugs

Bugs linked: 814152, 873853, 784086

---

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide

[Schievel1]

I don't know why pkgcheck scan --net reports a dead URL here. The ebuild works fine, and yes I deleted the files in /var/cache/distfiles/ to make sure.

[leio]

Once we are done with reviews and are happy with everything else, we might want to not git mv the ebuild revision, but keep the old one too, depending on if we deem this OK to "straight to stable" or not. But until this is in review, the git mv is making the review much easier thanks to providing a diff instead of a full new file.

[leio]

You also need gettext in BDEPEND - this is also missing from the autotools version, it looks like, but there it's pulled in indirectly by intltool - not the case with meson version anymore, and it's needed due to po/meson.build calling i18n.gettext() (the i18n might differ per projects, depends under what variable they imported the module, but there being a po/ folder is a good hint)

[leio]

also need virtual/pkgconfig in the live ebuild in BDEPEND - if it's not present, most of the dependency() meson calls would fail

[Schievel1]

Once we are done with reviews and are happy with everything else, we might want to not git mv the ebuild revision, but keep the old one too, depending on if we deem this OK to "straight to stable" or not. But until this is in review, the git mv is making the review much easier thanks to providing a diff instead of a full new file.

Idk what is the standard procedure here and if we should follow it. After all this is the same stable program, for 10 years or so now.

[leio]

This looks good to me now, except the non-live revbump should probably be a copy to new revision + ekeyword ~all on the new revision instead of a git mv with changes like in the PR. Though this allowed to review the changes much better, but is against policy to go in like that as straight to stable revbump to the main tree.

[Schievel1]

This looks good to me now, except the non-live revbump should probably be a copy to new revision + ekeyword ~all on the new revision instead of a git mv with changes like in the PR. Though this allowed to review the changes much better, but is against policy to go in like that as straight to stable revbump to the main tree.

Yup, did that. So unchanged r2 is back and r3 has the changes and is all unstable. I think we don't need to bother to stabilize r3, since you are releasing a new version anyway soon.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-10-24 13:23 UTC
Newest commit scanned: 4c09fe5
Status: ❌ broken

New issues caused by PR:
https://qa-reports.gentoo.org/output/gentoo-ci/bd08030ffd/output.html#app-office/planner

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/bd08030ffd/output.html