[Bug 1015868] Review Request: python-qutepart - Source code text editor component based on Qt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1015868

T.C. Hollingsworth <tchollingsworth@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|nobody@xxxxxxxxxxxxxxxxx    |tchollingsworth@xxxxxxxxx
              Flags|                            |fedora-review?



--- Comment #4 from T.C. Hollingsworth <tchollingsworth@xxxxxxxxx> ---
(In reply to Yajo from comment #3)
> Thanks. Fixed. RPM autorequires are like black magic to me. Definitely I
> need a sponsor.

They're not as complicated as they seem.  :-)

Every shared library on Unix-like operating systems contains a soname.  There
are a couple of ways you can see this soname:

% readelf -a /usr/lib64/libogg.so.0.8.0 | grep SONAME 
 0x000000000000000e (SONAME)             Library soname: [libogg.so.0]

% objdump -p /usr/lib64/libogg.so.0.8.0 | grep SONAME 
  SONAME               libogg.so.0

Also, it's common practice for there to exist a symlink from the soname to the
actual library file:

% ls -l /usr/lib64/libogg.so.0
lrwxrwxrwx. 1 root root 15 Apr 11  2013 /usr/lib64/libogg.so.0 ->
libogg.so.0.8.0

Any program can link to a shared library under a particular soname and expect
to continue to work as long as the library continues to provide that soname. 
(Of course, bumping soname is a manual process, so it's possible for a library
to break binary compatibility without bumping its soname, but that's considered
very bad behavior.)

You can see what libraries a program is linked to with the `ldd` command:

% ldd /usr/bin/ogginfo 
        linux-vdso.so.1 =>  (0x00007fff2fb95000)
        libvorbis.so.0 => /lib64/libvorbis.so.0 (0x000000399b200000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003984e00000)
        libogg.so.0 => /lib64/libogg.so.0 (0x000000399b600000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003984a00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003984600000)

RPM runs something like `objdump` to get the soname a library uses and adds
automatic Provides to the library package.  It also runs something like `ldd`
on programs to figure out what libraries they use and adds automatic Requires
to those packages, to eliminate the need for you to manually add those Requires
on your own.

This also isn't limited to binary libraries.  Perl has its own magic, as do
many other languages.

Anyway, RPM prior to the version included with Fedora 20 is dumb, and includes
Provides even for shared object files that exist outside the standard linker
path.  Python libraries are dlopen()ed by the Python interpreter, not linked,
so their sonames have no meaning.  It's thus necessary to remove them.

You can do this by excluding all automatic provides found within a certain
directory, as you did in your spec file, or by name, or with other less widely
used mechanisms.  The page I linked to it goes into this in excessive detail,
but it's not something you have to worry about very often, especially now that
RPM is getting smarter about them.

> I'd love it, but I hit bug #977632 when using fedora-packager-setup and
> another one when using https://koji.fedoraproject.org/koji/login, so I will
> use other method for now. Thanks, however.

Looking at the `fedora-packager-setup` bug, it seems to be python-fedora's
funny way of telling you that you entered your password wrong.  You really do
need to get this working, otherwise you won't be able to push a real build when
the time comes.  ;-)

If you continue to have trouble, you can contact Fedora Infrastructure for help
either by e-mailing admin@xxxxxxxxxxxxxxxxx or in #fedora-admin on IRC.

Please do get that working and link to a scratch build when you've got it
figured out.

Logging into the koji web interface is known to be broken, but it's a low
priority because pretty much the only thing you can do with it is cancel builds
(you can't start them), and you can do that with the `koji cancel-task` command
anyway, so nobody really cares.  :-/  Don't worry about it.

> Fixed. However Katepart is under LGPLv2:
> https://projects.kde.org/projects/kde/applications/kate/repository/revisions/
> master/entry/part/README

Ah, right you are.  Sorry for the confusion there.

> Sorry for that. For what I readed, I think you meant CFLAGS="%{optflags}",
> and that's what I put. Correct me if I'm wrong.

Yup.

> Thank you very much. Here are the results:
<snip>

Looking better now.  I'll proceed with the formal review shortly.

In the meantime, see if you can get going with koji.  Also, try giving a few
other packages an informal review:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Reviewing_packages

Package reviews are an important responsibility among maintainers, and we like
to see some evidence that new packagers are capable of doing them.  ;-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review





[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]