Bug 4041

Nice to see your attempt here, Mark. However, I think that the ToS (https://www.mendeley.com/terms/) prevent us from distributing modified versions (sections 4.1.2 and 4.3.* are relevant here). Do you have written permission from the authors? Coincidentally, I noticed you're using Fedora's copr service to distribute your RPMs. Please stop doing so immediately. You cannot use copr to distribute software not permissible in Fedora.

Having said that, I think your package could use some improvements. Please compare mine:
https://rathann.fedorapeople.org/review/mendeleydesktop/

A couple of highlights:
1. please enumerate the bundled code
2. include all the licenses (of the bundled code, as well) in the License: field
3. package the Libre/OpenOffice extension

I removed my package from COPR.

Thank you for your notes.

I did get permission to redistribute, at least through their forum. Do we need a more official email? 
I included pdf printouts here:
https://github.com/hmaarrfk/mendeley-rpm/blob/master/Mendeley%20Permission%20To%20Redistribute%20-%20generic.pdf
https://github.com/hmaarrfk/mendeley-rpm/blob/master/Mendeley%20Permission%20To%20Redistribute.pdf

I think you meant sections 2.x.x and not 4.x.x
Section 2.3.2 does mention copy/vary/modify, but I feel like 2.1.2 allows us to do so.

1. Do you mean in a separate "Provides" section? It seems the RPM tools do that automatically. Am I missing something?
2. Where did you get "LGPLv2+ and Mendeley and MIT and CC-BY-SA and (CPAL or AGPLv3) and BSD"
3. Honestly, I never used LibreOffice. I guess you've done an awesome job at that.

1. Wow, OK I understand what you did. You basically went through every binary that was inside mendeleydesktop and tried to find where it was from. You then went on and tried to find the license yourself.

2. Same as above.

3. I would think about it, but I would rather just help you maintain your spec file.

I think I would suggest that you add
rm  -rf share/icons/hicolor/48x48
rm  -rf share/icons/hicolor/64x64

in your spec file somewhere.
Their icons are lower resoluation have white instead of alpha, making them look rather bad. I just let gnome scale down the icons until they fix it, which they probably never will.

Hi,

I wanted to summarize the previous posts:

1. Is the permission I got from message boards enough to distribute Mendeley in RPMFusion? (See github pdfs)
2. Rathann, would you be OK if we modified your spec file since it is more complete than the one I developed?

Thanks,

Mark

(In reply to comment #4)
> 1. Is the permission I got from message boards enough to distribute Mendeley in
> RPMFusion? (See github pdfs)

That would be my understanding, but I'm not a lawyer.

> 2. Rathann, would you be OK if we modified your spec file since it is more
> complete than the one I developed?

Yes, feel free to do so. I see you reported the icon issue at http://support.mendeley.com/customer/portal/questions/1307459-badly-formatted-linux-icons but to be honest, I did take a look at both 48x48 and 64x64 icons and can't see anything wrong with them.

Created attachment 1568 [details]
Mendeley on the dock keeping icons 64 and 48

Created attachment 1569 [details]
Mendeley on the dock removing icons 64 and 48

Created attachment 1570 [details]
Mendeley icons 128, 64 and 48 side by side for comparison

Notice how the 128 has a black shadow, while the 64 has a white opaque color and 48 has some alpha to it.

Honestly, the inconsistency makes me just keep the 128 and let gnome scale it down to whatever it wants to use.

I added screenshots showing the problem. You can see that mendeley looks to have a white background. While it is not a horrendous mistake to have a white background, it is rather inconsistent and looks pretty ugly. The corners are not fully white and I find that the 128 pixel icon scaled down looks much better.

I see it now, thanks. Maybe adding these screenshots (especially the one from the dock with original 48px and 64px icons present) will make upstream understand your point.

Ok Mendeley's website is being problematic with me.

I can't even open links in chrome, nor can I post something to feedback.mendeley.com

I'm trying to suggest the following feature in Mendeley, but it isn't working:

For documentation purposes, (somebody can probably just copy paste this in)

Title: Fix linux icons for launcher

Body:
The 64x64 and 48x48 icons for linux have a white shadow instead of a black shadow. If you don't delete them, they make the icons look ungly and inconsistent. Deleting them forces your desktop environment to fallback on the 128x128 icon and scale it down.

With 64 and 48 icons:
https://bugzilla.rpmfusion.org/attachment.cgi?id=1568

without 64 and 48 icons
https://bugzilla.rpmfusion.org/attachment.cgi?id=1569

128 (top), 64(mid), and 48(bottom) icons for comparison
https://bugzilla.rpmfusion.org/attachment.cgi?id=1570

You can see the iconsistency in the shadow. 128 uses a black+alpha shadow. 64 uses an opaque white shadow. 48 uses a white+alpha shadow. I think the 128 is the correct one. 

This is a really easy fix.

You could recreate the 64 and 48 icons by downscaling the current 128 icon. Or you can just delete them.

In the meantime, it is probably worth upvoting this bug:
https://feedback.mendeley.com/forums/4941-general/suggestions/483646-provide-a-svg-version-of-the-application-icon

Reviving this bug because I think I addressed the previous issues. Thanks Dominik.

Full URLs to the spec file and source rpm of the package.
https://github.com/hmaarrfk/mendeley-rpm/
https://github.com/hmaarrfk/mendeley-rpm/releases/tag/1.17.6-3

Mendeley is a combination of a desktop application and a website which
helps you manage, share and discover both content and contacts in research.

This package is not eligible to be included in Fedora because it contains proprietary closed source code.

RPMLINT 64 bit: (32 bit package is similar)
rpmlint *.rpm
libreoffice-Mendeley.i486: E: explicit-lib-dependency libreoffice-core
libreoffice-Mendeley.x86_64: W: only-non-binary-in-usr-lib
libreoffice-Mendeley.x86_64: W: no-documentation
mendeleydesktop.src: W: spelling-error %description -l en_US Mendeley -> Mendeleev, Mendel, Melendez
mendeleydesktop.src: W: invalid-license Mendeley
mendeleydesktop.src:18: W: unversioned-explicit-provides bundled(citation-style-language)
mendeleydesktop.src:20: W: unversioned-explicit-provides bundled(citeproc-js)
mendeleydesktop.src:42: E: buildarch-instead-of-exclusivearch-tag i486
mendeleydesktop.x86_64: W: spelling-error %description -l en_US Mendeley -> Mendeleev, Mendel, Melendez
mendeleydesktop.x86_64: W: invalid-license Mendeley
mendeleydesktop.x86_64: E: invalid-soname /usr/lib64/libPDFNetC.so libPDFNetC.so
mendeleydesktop.x86_64: E: no-ldconfig-symlink /usr/lib64/libMendeley.so.1.17.6
mendeleydesktop.x86_64: W: shared-lib-calls-exit /usr/lib64/libMendeley.so.1.17.6 exit@GLIBC_2.2.5
mendeleydesktop.x86_64: W: no-manual-page-for-binary mendeleydesktop
mendeleydesktop-devel.x86_64: W: invalid-license Mendeley
mendeleydesktop-devel.x86_64: E: no-ldconfig-symlink /usr/lib64/libMendeley.so
mendeleydesktop-devel.x86_64: W: shared-lib-calls-exit /usr/lib64/libMendeley.so exit@GLIBC_2.2.5
mendeleydesktop-devel.x86_64: W: no-documentation
4 packages and 0 specfiles checked; 4 errors, 13 warnings.

I specify BuildArch because it makes it easier to program in i486 into the names of the %install section for x86 archs
I don't know what to do about the ldconfig error.
The other warnings/errors are due to the proprietary nature of the software.
The hard dependency is because the software generates text files and RPM will not autodetect the libreoffice dependency

This is my first RPM Fusion Package. I am seeking a sponsor.

(In reply to Mark Harfouche from comment #13)
> Reviving this bug because I think I addressed the previous issues. Thanks
> Dominik.
...
> This is my first RPM Fusion Package. I am seeking a sponsor.
Rathann can sponsor you.

You will likely need this for a proprietary software.
%global        debug_package %{nil}
%global        __strip /bin/true

Fedora default to i686 nowadays (-march), so if this binary is really built for i486, it could lead to issue. Anyone tested it there ? If it doesn't work one could also drop 32bit support.

I would prefer to use i686 even , as nobody knowns how dnf repo would handle such i486 package which was not anywhere common to use on fedora land. (we used i386, i586 or i686 for x86 32bit).
Anyway it's a minor issue as soon as it works.

Hi Nicolas
Thanks for replying.

(In reply to Nicolas Chauvet from comment #14)
> > This is my first RPM Fusion Package. I am seeking a sponsor.
> Rathann can sponsor you.
Thanks 
> You will likely need this for a proprietary software.
> %global        debug_package %{nil}
> %global        __strip /bin/true
https://github.com/hmaarrfk/mendeley-rpm/blob/master/mendeleydesktop.spec#L49

> Fedora default to i686 nowadays (-march), so if this binary is really built
> for i486, it could lead to issue. Anyone tested it there ? If it doesn't
> work one could also drop 32bit support.
Hoenstly, I don't own a 32bit computer anymore. I think it is i486 because the source for the binary has i486 in there.
It downloads as mendeleydesktop-1.17.10-linux-i486.tar.bz2

Also, adding the lines for i486 seems like work I wouldn't have done if the default compilation worked.

If you want, I could install a VM and test it, but I have a feeling we have all of 0 requests for a 32bit version.

(In reply to Mark Harfouche from comment #15)
...
> > Fedora default to i686 nowadays (-march), so if this binary is really built
> > for i486, it could lead to issue. Anyone tested it there ? If it doesn't
> > work one could also drop 32bit support.
> Hoenstly, I don't own a 32bit computer anymore. I think it is i486 because
Then maybe you can drop the i486 package and only package the x86_64 as ExclusiveArch: x86_64.

If any end-user would need the 32bit support, then they can contribute the packaging change.

Anyway, both options are possible.

Please try to use the %global defines on the top of the spec file (they have been added twice).

libMendeley.so is packaged in a -devel sub-package, but there is no header. Are you sure this symlink to the library isn't used at runtime ?

libPDFNetC is a library from another project. If you are using the pre-built version from Mendeley, it will conflicts if both packages are installed.
https://github.com/PDFTron/PDFNetWrappers

Instead you need to either:
- Package libPDFNetC (in fedora) and use the version built from source.
- Use a dedicated path, not registered to the system linker, so Mendeley can find it's libraries. (and add something like /usr/lib64/Mendeley to LD_LIBRARY_PATH).

(In reply to Nicolas Chauvet from comment #16)
[...]
> Then maybe you can drop the i486 package and only package the x86_64 as
> ExclusiveArch: x86_64.
> 
> If any end-user would need the 32bit support, then they can contribute the
> packaging change.
> 
> Anyway, both options are possible.

I agree it probably doesn't make sense to ship the 32bit x86 version unless there's demand for it.

> Please try to use the %global defines on the top of the spec file (they have
> been added twice).
> 
> libMendeley.so is packaged in a -devel sub-package, but there is no header.
> Are you sure this symlink to the library isn't used at runtime ?

There's no need for libMendeley.so at all. Only the versioned file and symlink are needed.

> libPDFNetC is a library from another project. If you are using the pre-built
> version from Mendeley, it will conflicts if both packages are installed.
> https://github.com/PDFTron/PDFNetWrappers

That contains only wrappers for PHP, Python and Ruby. The PDFNetC is still closed source: https://www.pdftron.com/pdfnet/downloads.html . The latest version (6.7.1) still bundles stuff like openssl-1.0.1c, libpng-1.6.12 and zlib-1.2.7.

I actually tried dropping the latest upstream version in place of the one bundled with MendeleyDesktop and it crashes on some PDFs I tried to import.

> Instead you need to either:
> - Package libPDFNetC (in fedora) and use the version built from source.

Impossible, sadly.

> - Use a dedicated path, not registered to the system linker, so Mendeley can
> find it's libraries. (and add something like /usr/lib64/Mendeley to
> LD_LIBRARY_PATH).

That'd be one option, as long as it's not added to the global LD_LIBRARY_PATH if you want to go all the way. However, in all likelihood, nothing else will ship libPDFNetC, so I'm not sure it's worth the trouble.

You can find my latest spec+patch here:
https://rathann.fedorapeople.org/nosrc/mendeleydesktop/

(In reply to Nicolas Chauvet from comment #14)
> (In reply to Mark Harfouche from comment #13)
> > Reviving this bug because I think I addressed the previous issues. Thanks
> > Dominik.
> ...
> > This is my first RPM Fusion Package. I am seeking a sponsor.
> Rathann can sponsor you.

I could, but I'd like to see some (informal) package reviews by Mark first.

> You will likely need this for a proprietary software.
> %global        debug_package %{nil}

Just the above is enough.

> %global        __strip /bin/true

This is not necessary.

Sorry, the lastest version is untested. Don't have access to Fedora at the moment.

(In reply to Dominik 'Rathann' Mierzejewski from comment #18)
> (In reply to Nicolas Chauvet from comment #14)
> > (In reply to Mark Harfouche from comment #13)
> > > Reviving this bug because I think I addressed the previous issues. Thanks
> > > Dominik.
> > ...
> > > This is my first RPM Fusion Package. I am seeking a sponsor.
> > Rathann can sponsor you.
> 
> I could, but I'd like to see some (informal) package reviews by Mark first.
> 

Ok, I'll get on the mailing list. I'll likely be super busy before Sept 6th. So there will be a delay.

(In reply to Nicolas Chauvet from comment #16)
> (In reply to Mark Harfouche from comment #15)
> ...
> > > Fedora default to i686 nowadays (-march), so if this binary is really built
> > > for i486, it could lead to issue. Anyone tested it there ? If it doesn't
> > > work one could also drop 32bit support.
> > Hoenstly, I don't own a 32bit computer anymore. I think it is i486 because
> Then maybe you can drop the i486 package and only package the x86_64 as
> ExclusiveArch: x86_64.
> 
> If any end-user would need the 32bit support, then they can contribute the
> packaging change.
> 
> Anyway, both options are possible.

32 bit support dropped.

> Please try to use the %global defines on the top of the spec file (they have
> been added twice).

Done

> libMendeley.so is packaged in a -devel sub-package, but there is no header.
> Are you sure this symlink to the library isn't used at runtime ?

-devel removed

> libPDFNetC is a library from another project. If you are using the pre-built
> version from Mendeley, it will conflicts if both packages are installed.
> https://github.com/PDFTron/PDFNetWrappers
> 
> Instead you need to either:
> - Package libPDFNetC (in fedora) and use the version built from source.
> - Use a dedicated path, not registered to the system linker, so Mendeley can
> find it's libraries. (and add something like /usr/lib64/Mendeley to
> LD_LIBRARY_PATH).
I think we can put this in libexec right?
I'll try to test things on my Fedora computer this weekend. 

(In reply to Dominik 'Rathann' Mierzejewski from comment #17)
> You can find my latest spec+patch here:
> https://rathann.fedorapeople.org/nosrc/mendeleydesktop/
Thanks! Found some missing bundled libraries. You are very thorough.

Assuming https://raw.githubusercontent.com/hmaarrfk/mendeley-rpm/master/mendeleydesktop.spec as the latest SPEC:


 - This is not needed anymore:

%post
update-desktop-database &> /dev/null || :
touch --no-create %{_datadir}/icons/hicolor &>/dev/null || :

%postun
if [ $1 -eq 0 ] ; then
    touch --no-create %{_datadir}/icons/hicolor &>/dev/null
    gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
fi
update-desktop-database &> /dev/null || :

%posttrans
gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :


 - %post libs -p /sbin/ldconfig
   %postun libs -p /sbin/ldconfig

   Use the brand new ldconfig macro instead:

%ldconfig_scriptlets

   See https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets for rationale.

(In reply to Mark Harfouche from comment #19)
> Sorry, the lastest version is untested. Don't have access to Fedora at the
> moment.
Please try to update the review as soon as possible.

I updated and tested it on my F27 machine.
See github.

WOMM.

(In reply to Mark Harfouche from comment #22)
Hi, what WOMM means ?

Works On My Machine.

(In reply to Mark Harfouche from comment #24)
> Works On My Machine.

You were expected to add the updated RPM links on this report.
Please consider to remind if the no communication by one week.
Also please consider reviewing others packages to show your skill in packaging so you can get sponsored.

There is no reason one review should take that much time.

Sorry Nicolas, I had totally forgotten about this.

I guess a lot has changed since 2016 and I no longer have Fedora installed.

Ultimately, I couldn't afford to stay on bleeding edge gcc (and the lib64 vs lib issue was getting too cumbersome)

I really appreciated everybody's help. 

A few people have found my package on github. If some of them want to take over they can probably reopen this issue.

Feel free to close this one.

Thx for your feedback. Closing.

Hello,
I would like to thank Mark Harfouche for the effort packaging Mendeley for Fedora. As noticed on the github, the application is updated to the latest stable release.

Here is the 
SPEC: https://raw.githubusercontent.com/hmaarrfk/mendeley-rpm/master/mendeleydesktop.spec
SRPM: https://github.com/hmaarrfk/mendeley-rpm/releases/download/1.19.2/mendeleydesktop-1.19.2-1.fc29.src.rpm

Since it is my first contribution to rpmfusion, I am seeking for sponsorship.

(In reply to Luya Tshimbalanga from comment #28)

> I am seeking for sponsorship.

It isn't required as your fedoraproject.org packager status is recognized here.
I note you haven't completed the CLA.

https://admin.rpmfusion.org/accounts/user/view/luya

1. Latest version is 1.19.3.

2. The application is available for i686 as well:
https://www.mendeley.com/download-desktop/
->
https://desktop-download.mendeley.com/download/linux/mendeleydesktop-1.19.3-linux-i486.tar.bz2

3. You're missing ExcludeArch: i686 x86_64

4. Why do you think you need this?

# seems like the executable is looking for this variable
# so I had to set it.
cat > bin/%{name} <<EOF
#!/bin/sh
export MENDELEY_BUNDLED_QT_PLUGIN_PATH=%{_libdir}/qt5/plugins
%{_libexecdir}/%{name} "$@"
EOF
chmod +x bin/%{name}

-> Is something not working without the above? In my testing, this is not required and you can install the binary directly in %{_bindir}:
install -Dpm755 lib/mendeleydesktop/libexec/%{name}.%{_target_cpu} %{buildroot}%{_bindir}/%{name}
if you patch the desktop file to run the executable with  --unix-distro-build option:

diff -up mendeleydesktop-1.16.1-linux-x86_64/share/applications/mendeleydesktop.desktop.r mendeleydesktop-1.16.1-linux-x86_64/share/applications/mendeleydesktop.desktop
--- mendeleydesktop-1.16.1-linux-x86_64/share/applications/mendeleydesktop.desktop.r	2016-03-22 12:58:52.000000000 +0100
+++ mendeleydesktop-1.16.1-linux-x86_64/share/applications/mendeleydesktop.desktop	2016-04-26 00:19:26.750302292 +0200
@@ -2,7 +2,7 @@
 Name=Mendeley Desktop
 GenericName=Research Paper Manager
 Comment=Mendeley Desktop is software for managing and sharing research papers
-Exec=mendeleydesktop %f
+Exec=mendeleydesktop --unix-distro-build %f
 Icon=mendeleydesktop
 Terminal=false
 Type=Application

(In reply to leigh scott from comment #29)
> (In reply to Luya Tshimbalanga from comment #28)
> 
> > I am seeking for sponsorship.
> 
> It isn't required as your fedoraproject.org packager status is recognized
> here.
> I note you haven't completed the CLA.
> 
> https://admin.rpmfusion.org/accounts/user/view/luya

Thanks, it is good to know. I completed the CLA.

(In reply to Dominik 'Rathann' Mierzejewski from comment #30)
> 1. Latest version is 1.19.3.

Fixed.

> 
> 2. The application is available for i686 as well:
> https://www.mendeley.com/download-desktop/
> ->mendeleydesktop-1.19.3-1.fc29.src.rpm
> https://desktop-download.mendeley.com/download/linux/mendeleydesktop-1.19.3-
> linux-i486.tar.bz2

Is there a better method to use a single tarball for both x86 and x86_64 other than conditional statemetn? Suggestion welcome
> 
> 3. You're missing ExcludeArch: i686 x86_64

Do you mean ExclusiveArch?

> 4. Why do you think you need this?
> 
> # seems like the executable is looking for this variable
> # so I had to set it.
> cat > bin/%{name} <<EOF
> #!/bin/sh
> export MENDELEY_BUNDLED_QT_PLUGIN_PATH=%{_libdir}/qt5/plugins
> %{_libexecdir}/%{name} "$@"
> EOF
> chmod +x bin/%{name}
> 
> -> Is something not working without the above? In my testing, this is not
> required and you can install the binary directly in %{_bindir}:
> install -Dpm755 lib/mendeleydesktop/libexec/%{name}.%{_target_cpu}
> %{buildroot}%{_bindir}/%{name}

Now the executable mendeleydesktop resulted:
mendeleydesktop 
Can't find Mendeley Desktop binary. Expected: /usr/bin/../../opt/mendeleydesktop/bin/mendeleydesktop
Unable to start Mendeley Desktop, the software may not be installed correctly.


> if you patch the desktop file to run the executable with 
> --unix-distro-build option:
> 
> diff -up
> mendeleydesktop-1.16.1-linux-x86_64/share/applications/mendeleydesktop.
> desktop.r
> mendeleydesktop-1.16.1-linux-x86_64/share/applications/mendeleydesktop.
> desktop
> ---
> mendeleydesktop-1.16.1-linux-x86_64/share/applications/mendeleydesktop.
> desktop.r	2016-03-22 12:58:52.000000000 +0100
> +++
> mendeleydesktop-1.16.1-linux-x86_64/share/applications/mendeleydesktop.
> desktop	2016-04-26 00:19:26.750302292 +0200
> @@ -2,7 +2,7 @@
>  Name=Mendeley Desktop
>  GenericName=Research Paper Manager
>  Comment=Mendeley Desktop is software for managing and sharing research
> papers
> -Exec=mendeleydesktop %f
> +Exec=mendeleydesktop --unix-distro-build %f
>  Icon=mendeleydesktop
>  Terminal=false
>  Type=Application

Done

Updated file
SRPM: https://github.com/luyatshimbalanga/mendeley-rpm/releases/download/1.19.3/mendeleydesktop-1.19.3-1.fc29.src.rpm
SPECS: https://raw.githubusercontent.com/luyatshimbalanga/mendeley-rpm/1.19.3/mendeleydesktop.spec

(In reply to Luya Tshimbalanga from comment #32)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #30)
[...]
> > 2. The application is available for i686 as well:
> > https://www.mendeley.com/download-desktop/
> > ->mendeleydesktop-1.19.3-1.fc29.src.rpm
> > https://desktop-download.mendeley.com/download/linux/mendeleydesktop-1.19.3-
> > linux-i486.tar.bz2
> 
> Is there a better method to use a single tarball for both x86 and x86_64
> other than conditional statemetn? Suggestion welcome

Actually you can't even do that. Making the Source: conditional is wrong and leads to non-reproducible SRPMs (i.e. if you rpmbuild -bs on x86_64 you'll only get the x86_64 tarball which won't work on i686). You have to include all tarballs in the SRPM unconditionally.

I'd suggest something like:
%prep
%ifarch i686
%setup -q -n mendeleydesktop-%{version}-linux-i486
%else
%setup -q -b 1 -T -n mendeleydesktop-%{version}-linux-%{_target_cpu}
%endif

> > 3. You're missing ExcludeArch: i686 x86_64
> 
> Do you mean ExclusiveArch?

Yes.

> > 4. Why do you think you need this?
> > 
> > # seems like the executable is looking for this variable
> > # so I had to set it.
> > cat > bin/%{name} <<EOF
> > #!/bin/sh
> > export MENDELEY_BUNDLED_QT_PLUGIN_PATH=%{_libdir}/qt5/plugins
> > %{_libexecdir}/%{name} "$@"
> > EOF
> > chmod +x bin/%{name}
> > 
> > -> Is something not working without the above? In my testing, this is not
> > required and you can install the binary directly in %{_bindir}:
> > install -Dpm755 lib/mendeleydesktop/libexec/%{name}.%{_target_cpu}
> > %{buildroot}%{_bindir}/%{name}
> 
> Now the executable mendeleydesktop resulted:
> mendeleydesktop 
> Can't find Mendeley Desktop binary. Expected:
> /usr/bin/../../opt/mendeleydesktop/bin/mendeleydesktop
> Unable to start Mendeley Desktop, the software may not be installed
> correctly.

Hm. Works for me: https://gitlab.com/greysector/mendeleydesktop/blob/master/mendeleydesktop.spec .

I can see you're including the python launcher:
install -Dpm755 bin/%{name} %{buildroot}%{_bindir}/%{name}
install -Dpm755 lib/mendeleydesktop/libexec/%{name}.%{_target_cpu} %{buildroot}%{_libexecdir}/%{name}

I used to do that in my package as well, but as of 1.16.1 I dropped the launcher, moved the binary to %{_bindir} and it works.

Why do you have this?
Requires: qt5-qtstyleplugins

Also,
# Needed to resolve shebang issue
BuildRequires: python3-devel
BuildRequires: /usr/bin/pathfix.py

python3-devel includes /usr/bin/pathfix.py (use %{_bindir}, by the way), so it's redundant.

Thanks for writing the appdata files.

Requires: %{name}%{?_isa} = %{version}-%{release}

Strict arched dependency is not actually necessary. The plugin communicates with mendeleydesktop over HTTP on localhost TCP socket, so you can mix i686 and x86_64 versions. You can leave it though.

(In reply to Dominik 'Rathann' Mierzejewski from comment #33)
> Actually you can't even do that. Making the Source: conditional is wrong and
> leads to non-reproducible SRPMs (i.e. if you rpmbuild -bs on x86_64 you'll
> only get the x86_64 tarball which won't work on i686). You have to include
> all tarballs in the SRPM unconditionally.
> 
> I'd suggest something like:
> %prep
> %ifarch i686
> %setup -q -n mendeleydesktop-%{version}-linux-i486
> %else
> %setup -q -b 1 -T -n mendeleydesktop-%{version}-linux-%{_target_cpu}
> %endif
> 

Done. I removed the no longer needed "-b 1 -T" parameters.

> > Now the executable mendeleydesktop resulted:
> > mendeleydesktop 
> > Can't find Mendeley Desktop binary. Expected:
> > /usr/bin/../../opt/mendeleydesktop/bin/mendeleydesktop
> > Unable to start Mendeley Desktop, the software may not be installed
> > correctly.
> 
> Hm. Works for me:
> https://gitlab.com/greysector/mendeleydesktop/blob/master/mendeleydesktop.
> spec .
> 
> I can see you're including the python launcher:
> install -Dpm755 bin/%{name} %{buildroot}%{_bindir}/%{name}
> install -Dpm755 lib/mendeleydesktop/libexec/%{name}.%{_target_cpu}
> %{buildroot}%{_libexecdir}/%{name}
> 
> I used to do that in my package as well, but as of 1.16.1 I dropped the
> launcher, moved the binary to %{_bindir} and it works.

Using that method allow the application to start after installing it.


> Why do you have this?
> Requires: qt5-qtstyleplugins

A remain from previous work. Removed.


> Also,
> # Needed to resolve shebang issue
> BuildRequires: python3-devel
> BuildRequires: /usr/bin/pathfix.py
> 
> python3-devel includes /usr/bin/pathfix.py (use %{_bindir}, by the way), so
> it's redundant.

Removed that redundancy.
 

> Thanks for writing the appdata files.
You are very welcome.

Here is the updated files
SPECS: https://raw.githubusercontent.com/luyatshimbalanga/mendeley-rpm/master/mendeleydesktop.spec
SRPMS: https://github.com/luyatshimbalanga/mendeley-rpm/releases/download/1.19.3/mendeleydesktop-1.19.3-2.fc29.src.rpm

> I'd suggest something like:
> %prep
> %ifarch i686
> %setup -q -n mendeleydesktop-%{version}-linux-i486
> %else
> %setup -q -b 1 -T -n mendeleydesktop-%{version}-linux-%{_target_cpu}
> %endif

I realized I could replace "mendeleydesktop" by %{name}. I will do it once approved.

Here is the updated files
SPECS: https://raw.githubusercontent.com/luyatshimbalanga/mendeley-rpm/master/mendeleydesktop.spec
SRPMS: https://github.com/luyatshimbalanga/mendeley-rpm/releases/download/1.19.5/mendeleydesktop-1.19.5-1.fc30.src.rpm

Updating from upstream following the reviewer suggestion unfortunately failed to execute.

Koji will probably choke on this


# Set exclusivity for x86 based architecture
%ifarch x86_64
ExclusiveArch:	x86_64 
%else
ExclusiveArch:	i686
%endif


Use

ExclusiveArch:	x86_64 i686


also change %{_target_cpu} to x86_64

%autosetup -p1 -n %{name}-%{version}-linux-%{_target_cpu}

(In reply to leigh scott from comment #39)
> Koji will probably choke on this
> 
> 
> # Set exclusivity for x86 based architecture
> %ifarch x86_64
> ExclusiveArch:	x86_64 
> %else
> ExclusiveArch:	i686
> %endif
> 
> 
> Use
> 
> ExclusiveArch:	x86_64 i686
> 
> 
> also change %{_target_cpu} to x86_64
> 
> %autosetup -p1 -n %{name}-%{version}-linux-%{_target_cpu}

Fixed.

What remained is the bundled qt library issue when attempting to install mendeleydesktop 

Error: 
 Problem: conflicting requests
  - nothing provides libQt5Core.so.5(Qt_5_PRIVATE_API)(64bit) needed by mendeleydesktop-1.19.5-1.fc30.x86_64
(try to add '--skip-broken' to skip uninstallable packages)

Awaiting for a proper alternative.

> What remained is the bundled qt library issue when attempting to install mendeleydesktop

You must unbundle it.

Then add to your SPEC:
%{?_qt5:Requires: %{_qt5}%{?_isa} = %{_qt5_version}}
BuildRequires: qt5-qtbase-private-devel

(In reply to Vitaly Zaitsev from comment #41)
> > What remained is the bundled qt library issue when attempting to install mendeleydesktop
> 
> You must unbundle it.
> 
> Then add to your SPEC:
> %{?_qt5:Requires: %{_qt5}%{?_isa} = %{_qt5_version}}
> BuildRequires: qt5-qtbase-private-devel

That wont fix the issue

$ ldd mendeleydesktop.x86_64 
./mendeleydesktop.x86_64: /lib64/libQt5Core.so.5: version `Qt_5_PRIVATE_API' not found (required by ./mendeleydesktop.x86_64)

Interesting enough, Fedora 27 version of qt5-qtbase provided the missing libQt5Core.so.5(Qt_5_PRIVATE_API) as seen on https://pkgs.org/download/libQt5Core.so.5(Qt_5_PRIVATE_API). I contacted upstream to address the issue. Hopefully a better alternative approach will be posted.

You can package 1.19.4, which doesn't require the private symbols, in the meantime.

By the way, does it still make sense to package the i686 version?

Better keep the i686 for the time being to prevent complaints. It will be removed in a future.

Here is the updated spec and srpms build for mendeley 1.19.4

SPEC: https://github.com/luyatshimbalanga/mendeley-rpm/blob/1.19.4/mendeleydesktop.spec

SRPMS: https://github.com/luyatshimbalanga/mendeley-rpm/releases/download/1.19.4/mendeleydesktop-1.19.4-1.fc30.x86_64.rpm

Some additional nitpicks:

%package -n libreoffice-Mendeley

-> should have archful dependencies on libreoffice-core:

Requires: libreoffice-core%{?_isa}


unzip openOfficePlugin/Mendeley-%{version}.oxt -d %{buildroot}%{loextdir}

-> maybe use unzip -qq for less verbose output (optional)

Looks good otherwise, so APPROVED.

Thank you for the review Donimique and Leight for the pointers. I will request new package right away.

And applied to packagers group.

Finally!

I'm confused, though: the ticket was by Mark Harfouche, but the approved package was Luya Tshimbalanga's. It appears that Mark closed the ticket in Sep 2018, and Luya resurrected it in Feb 2019.

The correct procedure per Fedora policy would have been to open a new ticket.

(In reply to Susi Lehtola from comment #49)
...
> The correct procedure per Fedora policy would have been to open a new ticket.
Indeed, this also apply to RPM Fusion, even as an admin we cannot bypass the process that easily, please submit a new review (that can be administratively accepted by an assigned reviewer).

From https://rpmfusion.org/Contributors#Create_a_package_review_request :

"Please do not submit more than one package per per Bugzilla entry. It would be very very difficult to follow the review otherwise. If you have related packages, it can be handy to trace all the dependencies using the "Depends On" or "Block" Bugzilla features."

Nevertheless, I will follow the procedure creating a new ticket: 

https://bugzilla.rpmfusion.org/show_bug.cgi?id=5287

(In reply to Luya Tshimbalanga from comment #51)
> From https://rpmfusion.org/Contributors#Create_a_package_review_request :
> 
> "Please do not submit more than one package per per Bugzilla entry. It would
> be very very difficult to follow the review otherwise. If you have related
> packages, it can be handy to trace all the dependencies using the "Depends
> On" or "Block" Bugzilla features."

You misunderstood. It says "one PACKAGE per BUG" (meaning, don't submit a single review request with three completely different packages in it), NOT "one bug per package".

(In reply to Nicolas Chauvet from comment #50)
> (In reply to Susi Lehtola from comment #49)
> ...
> > The correct procedure per Fedora policy would have been to open a new ticket.
> Indeed, this also apply to RPM Fusion, even as an admin we cannot bypass the
> process that easily, please submit a new review (that can be
> administratively accepted by an assigned reviewer).

You're right, guys. Sorry for missing this. I approved the new ticket and I'm closing this one.