[opensuse-packaging] Problem packaging icon file
Hi, I'm currently building a python 3 program, that will create a desktop file entry. The samepackaging sequence as for the python 2.7 does - surprisingly - not work. What I do: # menu-entry desktop-file-install --dir %{buildroot}%{_datadir}/applications % {name}.desktop %suse_update_desktop_file %{name} mkdir -p %{buildroot}%{_datadir}/pixmaps cp tryton/data/pixmaps/tryton/gnuhealth-icon.png %{buildroot}%{_datadir}/ pixmaps/gnuhealth.png That works *but* the rpm check moans about: gnuhealth-client.noarch: E: hardlink-across-partition (Badness: 10000) /usr/ lib/python3.6/site-packages/tryton/data/pixmaps/tryton/gnuhealth-icon.png / usr/share/pixmaps/gnuhealth.png [ 12s] Your package contains two files that are apparently hardlinked and that are [ 12s] likely on different partitions. Installation of such an RPM will fail due to [ 12s] RPM being unable to unpack the hardlink. do not hardlink across the first two [ 12s] levels of a path, e.g. between /srv/ftp and /srv/www or /etc and / usr. This is kinda strange - cp is not ln, no? Any ideas? Cheers Axel PS: https://build.opensuse.org/package/show/Application:ERP:Tryton:5.0/gnuhealth... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday 2019-09-13 19:30, Axel Braun wrote:
I'm currently building a python 3 program, that will create a desktop file entry. The samepackaging sequence as for the python 2.7 does - surprisingly - not work.
What I do: # menu-entry desktop-file-install --dir %{buildroot}%{_datadir}/applications % {name}.desktop %suse_update_desktop_file %{name}
mkdir -p %{buildroot}%{_datadir}/pixmaps cp tryton/data/pixmaps/tryton/gnuhealth-icon.png %{buildroot}%{_datadir}/ pixmaps/gnuhealth.png
That works *but* the rpm check moans about:
gnuhealth-client.noarch: E: hardlink-across-partition (Badness: 10000) /usr/ lib/python3.6/site-packages/tryton/data/pixmaps/tryton/gnuhealth-icon.png / usr/share/pixmaps/gnuhealth.png
/usr used to be one volume. Has this changed? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, I aggree with you "cp is not ln"... But fdupes detects when there are identical files in your package and it hardlinks them, as shown in the log file. [ 94s] + dupes -q -p -n -H -o name -r /home/abuild/rpmbuild/BUILDROOT/gnuhealth-client-35-8.1.x86_64 [...] [ 94s] + test -z /home/abuild/rpmbuild/BUILDROOT/gnuhealth-client-35-8.1.x86_64/usr/share/pixmaps/gnuhealth.png [ 94s] + test 0 = 1 [ 94s] + ln -f /home/abuild/rpmbuild/BUILDROOT/gnuhealth-client-35-8.1.x86_64/usr/lib/python3.7/site-packages/tryton/data/pixmaps/tryton/gnuhealth-icon.png /home/abuild/rpmbuild/BUILDROOT/gnuhealth-client-35-8.1.x86_64/usr/share/pixmaps/gnuhealth.png I think including icons in the python library path is a bad practice and you should avoid it. However, if you really need it, I do not know how to solve the problem (tune fdupes check? modify rpmlintrc?). I hope this helps. Best regards, Pascal. Le 13/09/2019 à 19:30, Axel Braun a écrit :
Hi,
I'm currently building a python 3 program, that will create a desktop file entry. The samepackaging sequence as for the python 2.7 does - surprisingly - not work.
What I do: # menu-entry desktop-file-install --dir %{buildroot}%{_datadir}/applications % {name}.desktop %suse_update_desktop_file %{name}
mkdir -p %{buildroot}%{_datadir}/pixmaps cp tryton/data/pixmaps/tryton/gnuhealth-icon.png %{buildroot}%{_datadir}/ pixmaps/gnuhealth.png
That works *but* the rpm check moans about:
gnuhealth-client.noarch: E: hardlink-across-partition (Badness: 10000) /usr/ lib/python3.6/site-packages/tryton/data/pixmaps/tryton/gnuhealth-icon.png / usr/share/pixmaps/gnuhealth.png [ 12s] Your package contains two files that are apparently hardlinked and that are [ 12s] likely on different partitions. Installation of such an RPM will fail due to [ 12s] RPM being unable to unpack the hardlink. do not hardlink across the first two [ 12s] levels of a path, e.g. between /srv/ftp and /srv/www or /etc and / usr.
This is kinda strange - cp is not ln, no? Any ideas? Cheers Axel
PS: https://build.opensuse.org/package/show/Application:ERP:Tryton:5.0/gnuhealth...
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hallo Pascal, Am Freitag, 13. September 2019, 20:03:08 CEST schrieben Sie:
I aggree with you "cp is not ln"... But fdupes detects when there are identical files in your package and it hardlinks them, as shown in the log file.
Indeed, looks I missed that!
[ 94s] + dupes -q -p -n -H -o name -r /home/abuild/rpmbuild/BUILDROOT/gnuhealth-client-35-8.1.x86_64 [...] [ 94s] + test -z /home/abuild/rpmbuild/BUILDROOT/gnuhealth-client-35-8.1.x86_64/usr/share/pi xmaps/gnuhealth.png [ 94s] + test 0 = 1 [ 94s] + ln -f /home/abuild/rpmbuild/BUILDROOT/gnuhealth-client-35-8.1.x86_64/usr/lib/pyth on3.7/site-packages/tryton/data/pixmaps/tryton/gnuhealth-icon.png /home/abuild/rpmbuild/BUILDROOT/gnuhealth-client-35-8.1.x86_64/usr/share/pi xmaps/gnuhealth.png
I think including icons in the python library path is a bad practice and you should avoid it. However, if you really need it, I do not know how to solve the problem (tune fdupes check? modify rpmlintrc?). I hope this helps.
Well, all the symbols needed for the GUI are placed in the python-subtree, as well as the icon for the desktop-file. I moved the icon file out of the python-subtree, so fdupes can't complain any longer. Now it builds. Thanks Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (3)
-
Axel Braun
-
Jan Engelhardt
-
Pascal COMBES