- Bump to 2.2.14

Package approved.


Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed



===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "Unknown or generated", "GPL (v3 or later)", "GPL (v2 or
     later)". 304 files have unknown license. Detailed output of
     licensecheck in /home/bob/packaging/review/elementary-planner/review-
     elementary-planner/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[x]: Package requires other packages for directories it uses.
     Note: No known owner of /usr/share/locale/mo/LC_MESSAGES,
     /usr/share/locale/mo
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: The spec file handles locales properly.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 10240 bytes in 2 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %license.
[x]: Package does not own files or directories owned by other packages.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package contains desktop file if it is a GUI application.
[x]: Package installs a %{name}.desktop using desktop-file-install or
     desktop-file-validate if there is such a file.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Sources are verified with gpgverify first in %prep if upstream
     publishes signatures.
     Note: gpgverify is not used.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Fully versioned dependency in subpackages if applicable.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on debuginfo package(s).
     Note: No rpmlint messages.
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: elementary-planner-2.1.1-2.fc33.x86_64.rpm
          elementary-planner-debuginfo-2.1.1-2.fc33.x86_64.rpm
          elementary-planner-debugsource-2.1.1-2.fc33.x86_64.rpm
          elementary-planner-2.1.1-2.fc33.src.rpm
elementary-planner.x86_64: W: spelling-error %description -l en_US duedate -> due date, due-date, educated
elementary-planner.x86_64: W: no-manual-page-for-binary com.github.alainm23.planner
elementary-planner.x86_64: E: invalid-lc-messages-dir /usr/share/locale/bh/LC_MESSAGES/com.github.alainm23.planner.mo
elementary-planner.x86_64: E: invalid-lc-messages-dir /usr/share/locale/mo/LC_MESSAGES/com.github.alainm23.planner.mo
elementary-planner.src: W: spelling-error %description -l en_US duedate -> due date, due-date, educated
4 packages and 0 specfiles checked; 2 errors, 3 warnings.

(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/elementary-planner

Why are you arbitrarily inventing an "elementary-" prefix for the package name?
All existing elementary-foo packages come from the github.com/elementary organisation, this one does not.

And why are you arbitrarily building this with -flto? Packages should be built with fedora default build flags ...

FEDORA-2020-777b9bd7bf has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-777b9bd7bf

FEDORA-2020-58dad2a040 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-58dad2a040

FEDORA-2020-777b9bd7bf has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2020-777b9bd7bf \*`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-777b9bd7bf

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-58dad2a040 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2020-58dad2a040 \*`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-58dad2a040

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-777b9bd7bf has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-58dad2a040 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Can you please respond to https://bugzilla.redhat.com/show_bug.cgi?id=1805928#c3 ?

(In reply to Fabio Valentini from comment #3)
> Why are you arbitrarily inventing an "elementary-" prefix for the package
> name?

Because there is already exist 'planner' package https://src.fedoraproject.org/rpms/planner
Also there is no any special Elementary guidelines in Fedora and how elementary packages MUST named.

> And why are you arbitrarily building this with -flto?

Why you not ask why arbitrarily mozjs [1] and firefox built with -flto and why LTO by default proposed in F32 [2]?

> Packages should be built with fedora default build flags ...

This package built with default fedora build flags. Additional build flags not prohibited, i asked this many times other maintainers.

[1] https://src.fedoraproject.org/rpms/mozjs68/blob/master/f/mozjs68.spec#_3
[2] https://fedoraproject.org/wiki/LTOByDefault

(In reply to Artem from comment #11)
> (In reply to Fabio Valentini from comment #3)
> > Why are you arbitrarily inventing an "elementary-" prefix for the package
> > name?
> 
> Because there is already exist 'planner' package
> https://src.fedoraproject.org/rpms/planner
> Also there is no any special Elementary guidelines in Fedora and how
> elementary packages MUST named.

Uh ... that's my point, it's *not* an elementary project.
It's a third-party project, that doesn't have "elementary" anywhere in its name.
I know that "planner" is a really generic name that's likely to lead to name clashes (as it does in this case), but that doesn't mean you can just "invent" a name prefix.

> > And why are you arbitrarily building this with -flto?
> 
> Why you not ask why arbitrarily mozjs [1] and firefox built with -flto and
> why LTO by default proposed in F32 [2]?
> 
> > Packages should be built with fedora default build flags ...
> 
> This package built with default fedora build flags. Additional build flags
> not prohibited, i asked this many times other maintainers.

Fair enough, but the packaging Guidelines still specify that you should document *why* you're modifying build flags.

The Change about enabling LTO by default also has no bearing on this, because it would change the *default* build flags, and thereby *by definiton* moving the goalpost for everybody.

> [1] https://src.fedoraproject.org/rpms/mozjs68/blob/master/f/mozjs68.spec#_3
> [2] https://fedoraproject.org/wiki/LTOByDefault

> Uh ... that's my point, it's *not* an elementary project.

Seems like we have some misunderstanding there, but that's obviously since you asking meta questions. So what's exactly a problem here? You still didn't said. What is a real fix for this specifically case since there already 'planner' package exist in Fedora? And why you asking like i did something criminal since *you* as person who responsible for Elementary stack didn't wrote any guidelines for it?

> Fair enough, but the packaging Guidelines still specify that you should document *why* you're modifying build flags.

In case with LTO this is obvious why and as you already seen other maintainers not specify too why they build with LTO. But sometimes i document even how much profit we got there in percentage ratio, see [1]. So i am not "arbitrarily" building with -flto, as you stated.

> The Change about enabling LTO by default also has no bearing on this, because it would change the *default* build flags, and thereby *by definiton* moving the goalpost for everybody.

One again, since you asking meta question i have no idea what has bearing on this and what doesn't for you. And you quoting wrong thesis. Thesis was why i enabling LTO in *some* my package. Answer was for the same reason that mozjs did and for the same reason why it was proposed to enable it by default in F32. And i asked many times other maintainers about LTO specifically and there is nothing wrong with that.

[1] https://src.fedoraproject.org/rpms/kakoune/blob/master/f/kakoune.spec#_3

(In reply to Artem from comment #13)
> Seems like we have some misunderstanding there, but that's obviously since
> you asking meta questions. So what's exactly a problem here? You still
> didn't said. What is a real fix for this specifically case since there
> already 'planner' package exist in Fedora? And why you asking like i did
> something criminal since *you* as person who responsible for Elementary
> stack didn't wrote any guidelines for it?

Why should there be specific Guidelines for elementary stuff?
All their projects are now 99% standard, simple meson projects, where the general guidelines are definitely enough.
There are also no Packaging Guidelines for GNOME, KDE, XFCE, etc. ... because it's not necessary.

That said, there *are* Guidelines for package Naming, specifically:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_general_naming

But well, the package is named "elementary-planner" now, even though it's not an official elementary project.
At least on NixOS, they have the same problem and they also named it "elementary-planner" despite it not being an official elementary project, so at least some distros are somewhat consistent here.

Also note that the original "planner" package is also no longer present on fedora 32+ (it was retired, probably because it didn't build anymore on F31+, or because somebody just orphaned it), so you could eventually rename this package and drop the "elementary-" prefix.

> > Fair enough, but the packaging Guidelines still specify that you should document *why* you're modifying build flags.
> 
> In case with LTO this is obvious why and as you already seen other
> maintainers not specify too why they build with LTO. But sometimes i
> document even how much profit we got there in percentage ratio, see [1]. So
> i am not "arbitrarily" building with -flto, as you stated.

Side note: I have not seen any package enabling LTO before I looked at this one. There may be "many", but this is the first one I'm interacting with. So I was just surprised that it's there without a comment.

While you're right that it might be obvious what -flto does, but it might not be obvious to everybody! That's why a comment is always nice, if only to say "this flag enables link-time optimizations to make the application run faster" ...

> > The Change about enabling LTO by default also has no bearing on this, because it would change the *default* build flags, and thereby *by definiton* moving the goalpost for everybody.
> 
> One again, since you asking meta question i have no idea what has bearing on
> this and what doesn't for you. And you quoting wrong thesis. Thesis was why
> i enabling LTO in *some* my package. Answer was for the same reason that
> mozjs did and for the same reason why it was proposed to enable it by
> default in F32. And i asked many times other maintainers about LTO
> specifically and there is nothing wrong with that.
> 
> [1] https://src.fedoraproject.org/rpms/kakoune/blob/master/f/kakoune.spec#_3

> Why you not ask why arbitrarily mozjs [1] and firefox built with -flto and
> why LTO by default proposed in F32 [2]?

I suppose you wanted to say "duh, of course adding -flto makes things run faster, why is he even asking" here? I probably misunderstood this paragraph when I first read it ...

I know what compiling with -flto does, I wasn't asking for myself, but for people who might *not know*. Maybe that answers your question?

---

I'm sorry if my questions seemed like nonsense to you. That was not my intention.

If you just said "I'm not modifying the build flags (so this is okay), I'm only adding LTO to make this run faster, maybe I'll add this as a comment to the .spec file with the next update" I would have been 100% satisfied. Again, I apologize if my questions were too "meta".

No prob at all. :) I almost always try to build first without LTO and then with LTO and trying to see at least any difference in footprint since not always possible to do some benchmarks. And TBH this is not the case with 'planner' and it even produce a little bit bigger binary with LTO which is very very rare case, at least in my experience. So i started unwittingly to think that you did your own research and found this and instead of just saying this clearly asking meta questions. Usually in similar Vala apps not to much profit from enabling LTO but still some. Anyway i already rebuilt it (for Rawhide at this moment) without LTO. Just some interesting facts: few libs which i tested have up to 40% profit in terms of produced binary size. Asked many times compiler guys and they said that nowadays the only drawback with LTO is that it can produce less useful debug info which can make things harder to debug.

As for naming package this is first elementary package which i named with elementary prefix and only because of we already have package with 'planner' name. And i really didn't know in what cases some elementary apps should use this prefix until you explain. I found one your package 'elementary-code' and i though you named it like that for the same reason because there is already exist package 'code'. :) For sure we need to rename it to 'planner' then, but there is still a problem that 'planner' already build for F31...