Hi Amirerfan. I'm not a packager yet, but I have some things to point out about your spec file:

* Use a more descriptive Source0

Source0:        %{url}/archive/v%{version}/%{name}-%{version}.tar.gz

* You can install the README.md as a document file

%doc README.md

* Bogus date in %changelog (should be Wednesday instead of Tuesday)

* Wed Aug 04 2021 Amirerfan Rafati <aerfanr> - 1.9.0-1

Also, use a direct link for your SRPM, like this:

SRPM URL: https://download.copr.fedorainfracloud.org/results/aerfanr/birdtray/fedora-rawhide-x86_64/02362872-birdtray/birdtray-1.9.0-1.fc35.src.rpm

(In reply to Gustavo Costa from comment #1)
> Hi Amirerfan. I'm not a packager yet, but I have some things to point out
> about your spec file:
> 
> * Use a more descriptive Source0
> 
> Source0:        %{url}/archive/v%{version}/%{name}-%{version}.tar.gz
> 
> * You can install the README.md as a document file
> 
> %doc README.md
> 
> * Bogus date in %changelog (should be Wednesday instead of Tuesday)
> 
> * Wed Aug 04 2021 Amirerfan Rafati <aerfanr> - 1.9.0-1
> 
> Also, use a direct link for your SRPM, like this:
> 
> SRPM URL:
> https://download.copr.fedorainfracloud.org/results/aerfanr/birdtray/fedora-
> rawhide-x86_64/02362872-birdtray/birdtray-1.9.0-1.fc35.src.rpm

Hello there. Thank you for your response.
I have considered your points and applied necessary modifications. The only concern is that there is a build section in the README.md file. According to Fedora Packaging guide, we should not include build instructors. It also includes installation instructions for Microsoft Windows. What should I do about that? Should I include the README.MD as is or should I ask upstream to create a separate  documentation for Linux without the build instructions?

I'm also not sure about this, but I think it's fine to include the README.md. I have seen some packages using READMEs files that include build instructions or Microsoft Windows stuff:

https://src.fedoraproject.org/rpms/ghostwriter/blob/rawhide/f/ghostwriter.spec
https://src.fedoraproject.org/rpms/anki/blob/rawhide/f/anki.spec
https://src.fedoraproject.org/rpms/rust-git-delta/blob/rawhide/f/rust-git-delta.spec
https://src.fedoraproject.org/rpms/qbittorrent/blob/rawhide/f/qbittorrent.spec
https://src.fedoraproject.org/rpms/micro/blob/rawhide/f/micro.spec

We can wait for an official review too.

Hello.  I am not a packager yet so this is an unofficial review.

I attempted to run fedora-review against this bugzilla and got the following:

yoga➜  reviews  ᐅ  fedora-review -b 1989943         
INFO: Processing bugzilla bug: 1989943
INFO: Getting .spec and .srpm Urls from : 1989943
INFO:   --> SRPM url: https://download.copr.fedorainfracloud.org/results/aerfanr/birdtray/fedora-rawhide-x86_64/02362872-birdtray/birdtray-1.9.0-1.fc35.src.rpm
INFO:   --> Spec url: https://src.fedoraproject.org/rpms/micro/blob/rawhide/f/micro.spec
INFO: Using review directory: /home/rcallicotte/Projects/packaging/reviews/1989943-micro
INFO: Downloading .spec and .srpm files
ERROR: 'Error HTTP Error 404: Not Found downloading https://download.copr.fedorainfracloud.org/results/aerfanr/birdtray/fedora-rawhide-x86_64/02362872-birdtray/birdtray-1.9.0-1.fc35.src.rpm' (logs in /home/rcallicotte/.cache/fedora-review.log)

The source RPM does not exist.  Perhaps you could update this issue with another link?

-Robby

I've been compiling this package from source since RHEL 7, and then again with RHEL 8. Now with RHEL 9, I'm going through the process again.
 
In short, this is a really useful Thunderbird addon, with an active upstream project. The code itself is of a relatively high quality (certainly higher than Thunerbird itself), and based on my usage, its been stable. I've used it rather extensively with Gnome on my RHEL 7 then 8 machine, which used Xorg. And to a lesser extent, on my Fedora 34, 35, and now 36 machine, which uses Wayland.

There is a potential blocker though. I noticed an upstream issue was reported by someone running Arch, who had trouble birdtray segfaulting on their Plasma desktop. The upstream is issue is still pending, but since the Qt5 version, 5.15.2 reported is the same shipped with RHEL 9, and because Fedora 36, with 5.15.3 is also close, it would be nice if a Plasma aficionado, who uses Plasma and Thunderbird on a daily basis, could give it try before its officially released.

Otherwise this package has my vote to become an official Fedora package. If it gets cleared, Id be happy to give the spec file a through review. 

P.S. I'm about to compile the latest upstream snapshot for RHEL 9, so I can start testing that. My hope is that if it doesn't generate bug reports from Fedora users, and it runs stable in my environment for the next 3-4 months, then it can also become an EPEL 9 package.

Just to be clear, Amirerfan, I take you are volunteering to be the package maintainer?

And for completeness, the GH issue on packaging:

https://github.com/gyunaev/birdtray/issues/481

And the Plasma segfault I mentioned:

https://github.com/gyunaev/birdtray/issues/500

"it would be nice if a Plasma aficionado, who uses Plasma and Thunderbird on a daily basis, could give it try"

Here I am

It does indeed segfault immediately on launch (F36 Plasma and Thunderbird, fully updated)

I also regenerated the SPEC/SRPM for completeness:

SPEC: https://fuller.fedorapeople.org/birdtray.spec
SRPM: https://fuller.fedorapeople.org/birdtray-1.9.0-2.fc36.src.rpm

If this gets fixed and a package maintainer is needed, I can also take it

Hi Mark. Thank you for testing it out. It seems the conversation is getting split between here and the GH issue ( https://github.com/gyunaev/birdtray/issues/500#issuecomment-1170229177 ). The original Arch user tried using this branch ( https://github.com/gyunaev/birdtray/pull/434 ) and reported that it eliminated the segfaults. He was using a newer version of QT though, and even though it ran just fine, Birdtray wasn't finding the Thunderbird window properly. Without any logs or error messages to go off, it was hard to know where to start looking so I was hoping to try it on my own dev system next week, when I have time - since I don't have Plasma installed/setup on this computer.

You can read the GH post, but I was able to replicate the issue using `QT_QPA_PLATFORM=wayland birdtray` but that was running a Gnome desktop. And I fixed it by using `XDG_SESSION_TYPE=wayland birdtray` which was my environment provided by default. That led me to suspect something in the shell environment might be confusing some of the code as to what environnent it's running under, which would explain why it can't "find" the Thunderbird window. You might try manipulating and/or removing the default environment variables, and seeing what happens.

Assumning that PR does indeed fix the segault.

I should probably mention in both places. If you do play around with this more, you should probably run birdtray via the console. I also think there might environent variables you can tweak that will cause the QT libs to output more info/warnings. You can also try using ` XDG_CURRENT_DESKTOP=KDE` standalone and/or with the QT var I mentioned above.

It also just occurred to me. You should check the systemd journal. It might contain a clue as well. I think new versions of QT log messages there by default. See the `QT_LOGGING_RULES`  and `QT_MESSAGE_PATTERN` ...

Hi Mark, This could be the default, but can you also try running the PR version, and the HEAD commit with:

env DESKTOP_SESSION=plasma XDG_CURRENT_DESKTOP=KDE birdtray

That ran just fine for me, but it was with a Gnome desktop. You can also experiment with various QT platform plugins like so.

env DESKTOP_SESSION=plasma XDG_CURRENT_DESKTOP=KDE QT_QPA_PLATFORM=wayland birdtray

Substitute `wayland` with other plugins. Some possibilities are: eglfs, linuxfb, minimal, minimalegl,, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx and more (or less) depending on what you have installed.

I am glad that @mark.e.fuller is volunteering to maintain this package, because I probably cannot maintain it.

Also I do not have access to any Fedora system with Plasma installed right now but as I said in the GitHub issue, I did not manage to make Birdtray compiled from AUR work on Plasma Wayland with Qt version 5.15.5. The environment variables also did not work. It works fine on Plasma X11.

(In reply to Mark E. Fuller from comment #7)

> If this gets fixed and a package maintainer is needed, I can also take it

And I can review it.
PS. koji builds for F36+ and EPEL9- are welcome

Spec URL: https://tieugene.fedorapeople.org/rpms/birdtray/birdtray.spec
SRPM URL: https://tieugene.fedorapeople.org/rpms/birdtray/birdtray-1.10.0-1.20221117gitc495497.fc36.src.rpm
Description: Birdtray is a system tray new mail notification for Thunderbird, which does not require extensions.
Fedora Account System Username: tieugene

Koji F37 build: https://koji.fedoraproject.org/koji/taskinfo?taskID=94372434

So finally, what is the update here? I'd love to see this officially as a Fedora package. How can I help?

(In reply to Bogomil Shopov from comment #15)
> So finally, what is the update here? I'd love to see this officially as a
> Fedora package. How can I help?

1. Kick the author to clean/update the package
2. Review it (package, not author)

This is an automatic check from review-stats script.

This review request ticket hasn't been updated for some time. We're sorry
it is taking so long. If you're still interested in packaging this software
into Fedora repositories, please respond to this comment clearing the
NEEDINFO flag.

You may want to update the specfile and the src.rpm to the latest version
available and to propose a review swap on Fedora devel mailing list to increase
chances to have your package reviewed. If this is your first package and you
need a sponsor, you may want to post some informal reviews. Read more at
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group.

Without any reply, this request will shortly be considered abandoned
and will be closed.
Thank you for your patience.

This is an automatic action taken by review-stats script.

The ticket submitter failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we consider this ticket as DEADREVIEW and proceed to close it.