https://bugzilla.redhat.com/show_bug.cgi?id=1100925 --- Comment #8 from Igor Gnatenko <i.gnatenko.brain@xxxxxxxxx> --- (In reply to David Tardon from comment #7) > (In reply to David Tardon from comment #5) > > (In reply to Igor Gnatenko from comment #3) > > > - librevenge.x86_64: W: unused-direct-shlib-dependency > > > /usr/lib64/librevenge-generators-0.0.so.0.0.0 /lib64/libm.so.6 > > Or does this mean that librevenge-generators-0.0.so.0.0.0 needs on > libm.so.6, even though it does not use it? If so, then I can only repeat > that libm.so.6 is already needed by libstdc++.so.6, so I do not see this as > a problem. This mean, that you linked with libm.so, but librevenge doesn't using it.(In reply to David Tardon from comment #5) > (In reply to Igor Gnatenko from comment #3) > > - Package contains BR: python2-devel or python3-devel > > -> I don't know what happens.. > > Nonsense. There is no such BR. > > > > > - librevenge.x86_64: W: unused-direct-shlib-dependency > > /usr/lib64/librevenge-generators-0.0.so.0.0.0 /lib64/libm.so.6 > > -> See: > > http://fedoraproject.org/wiki/Common_Rpmlint_issues#unused-direct-shlib-dependency > > readelf -d > review-librevenge/rpms-unpacked/librevenge-0.0.0-1.fc20.x86_64.rpm/usr/lib64/ > librevenge-0.0.so.0 | grep NEEDED > 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] > 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] > 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] > 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] > > I do not see any explicit dependency on librevenge-generators... And I do > not see libm.so.6 as a problem, as libstdc++.so.6 already needs it anyway. > > > > > - GPL (v3 or later) > > - ----------------- > > - librevenge-0.0.0/data/gdb/auto-load/librevenge-0.0.py > > - librevenge-0.0.0/data/gdb/auto-load/librevenge-stream-0.0.py > > -> I think you forget to add this license to list. Probably you should > > replace LGPLv2+ with GPLv3+ or something > > This is apparently checked on unpatched tarball. Patch1 changes these > licenses to MPLv2.0/LGPLv2+. (I adapted the pretty printers code from > another project of mine and forgot to change the licenses originally.) I think unpatched tarball, because %autosetup doesn't work with fedora-review. is this fedora-review or mock bug ? > > > > > - Patches link to upstream bugs/comments/lists or are otherwise justified. > > -> there no links. could you provide it ? If no - sent to upstream. NOT > > BLOCKER. > > These patches come from upstream. ack. > > > > > - Packages should try to preserve timestamps of original installed files. > > -> I think you could patch it. there need '-p' for `install` command. NOT > > BLOCKER. > > I do not call install manually anywhere... calls to install becomes from Makefile.* you can see in logs something like this: install -c -m 0644 blahblah /usr/share/blahblah and more better if we will see '-p' there. -p, --preserve-timestamps apply access/modification times of SOURCE files to corresponding destination files > > > > > - Package must own all directories that it creates. > > Note: Directories without known owners: /usr/share/gdb > > libstdc++ owns this on my system. > > > -> I think for -devel subpackage should be Requires: libstdc++ > > libstdc++ is already required through librevenge. yeah. seems fedora-review bug. > > > - Package does not own files or directories owned by other packages. > > Note: Dirs in package are owned also by: /usr/share/gdb/auto- > > load/usr(libstdc++), /usr/share/gdb/auto-load(libstdc++, gdb), > > /usr/share/gdb/auto-load/usr/lib64(libstdc++) > > -> do not own this dirs. it will be owned by libstdc++. own only files in > > this directories > > All right, removed. (In reply to David Tardon from comment #4) > (In reply to Igor Gnatenko from comment #2) > > > Source: http://downloads.sourceforge.net/libwpd/%{name}-%{version}.tar.xz > > use Source0 instead of Source. > > Why? 19 of my 30 packages (not all of them created by myself) use just > Source and nobody has ever complained to me. That's not critical. But good practice. https://fedoraproject.org/wiki/Packaging:SourceURL. anywhere Source0. > > > > > > %autosetup -p1 > > use %setup -q and %patch0 -p1, %patch1 -p1 > > No. There is no chance this is ever going to be backported to EPEL-6. hm. Why ? AFAIK there present setup and patch macroses. http://pkgs.fedoraproject.org/cgit/zabbix.git/tree/zabbix.spec#n273 zabbix available for EL6 and (IIRC) EL5. Please change this macroses. > > > > > >make install DESTDIR=%{buildroot} > > you could use %make_install instead, but that's not should item. > > I am pretty sure that the use of %make_install is prohibited in Fedora. it's available for EL6 and probably for EL5. [root@monitoring ~]# rpm --eval %make_install make install DESTDIR=/root/rpmbuild/BUILDROOT/%{name}-%{version}-%{release}.x86_64 [root@monitoring ~]# cat /etc/redhat-release CentOS release 6.5 (Final) -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review