Bug 623425 - Review Request: python-pyside - Python bindings for Qt4
Summary: Review Request: python-pyside - Python bindings for Qt4
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Orcan Ogetbil
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-11 18:45 UTC by Kalev Lember
Modified: 2019-01-09 12:33 UTC (History)
9 users (show)

Fixed In Version: shiboken-0.5.0-2.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-30 06:12:38 UTC
Type: ---
Embargoed:
oget.fedora: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Kalev Lember 2010-08-11 18:45:47 UTC
Spec URL: http://kalev.fedorapeople.org/python-pyside.spec
SRPM URL: http://kalev.fedorapeople.org/python-pyside-0.4.0-1.fc15.src.rpm
Description:
PySide provides Python bindings for the Qt cross-platform application
and UI framework. PySide consists of a full set of Qt bindings, being
compatible with PyQt4 API 2.

Comment 1 Kalev Lember 2010-08-11 18:56:39 UTC
Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2393958

Note that currently python-pyside is only buildable in rawhide; in F-13 and F-14 all the deps aren't new enough. I'm planning to eventually build latest python-pyside and the deps in F-13 and F-14, but I'd like to first make sure everything works fine in rawhide before asking releng to do numerous buildroot overrides.

Two unit tests are failing:
 - QtMultimedia_audio_test dies with assertion in pulseaudio code
 - QtGui_bug_243 fails on i686 but passes on x86_64; I'm working with upstream
   to figure out the cause.

Comment 2 Chen Lei 2010-08-12 12:36:20 UTC
Will it be better to rename it to python-PySide? It seems pyside actually use PySide as the namespace for module names and include dir.

Comment 3 Kalev Lember 2010-08-12 13:15:55 UTC
Main reason why I chose the name "python-pyside" is to match Debian naming for consistency: http://packages.debian.org/sid/python-pyside

Comment 4 Chen Lei 2010-08-12 13:54:14 UTC
(In reply to comment #3)
> Main reason why I chose the name "python-pyside" is to match Debian naming for
> consistency: http://packages.debian.org/sid/python-pyside    

Actually, debian/gentoo don't allow package names with capital letters :)

e.g.
http://packages.debian.org/source/sid/python-qt4


FYI, upstream use PySide instead of pyside[1] and fedora naming guideline for python addons also mentions "When in doubt, use the name of the module that you type to import it in a script"[2]. So I suggest use python-PySide instead of python-pyside.

[1]http://www.pyside.org/faq/
[2]http://fedoraproject.org/wiki/PackageNamingGuidelines#Addon_Packages_.28python_modules.29

Comment 5 Chen Lei 2010-08-12 14:06:12 UTC
It seems pyside has a phonon binding, would you mind to check if phonon-devel is necessary for pyside?

Comment 6 Kalev Lember 2010-08-12 15:07:18 UTC
(In reply to comment #4)
> FYI, upstream use PySide instead of pyside[1] and fedora naming guideline for
> python addons also mentions "When in doubt, use the name of the module that you
> type to import it in a script"[2]

Depends on where you look. Upstream pages which talk about packaging or repos use lower case pyside:
http://www.pyside.org/downloads/
http://qt.gitorious.org/pyside/

Besides that, Fedora Naming Guidelines say:
"If this package has been packaged by other distributions/packagers in the past, then you should try to match their name for consistency."
so I think it makes sense to follow Debian lead here.

Comment 7 Kalev Lember 2010-08-12 15:11:00 UTC
(In reply to comment #5)
> It seems pyside has a phonon binding, would you mind to check if phonon-devel
> is necessary for pyside?    

Good catch, thanks.

* Thu Aug 12 2010 Kalev Lember <kalev> - 0.4.0-2
- Added missing phonon-devel and qt-webkit-devel deps (#623425)

Spec URL: http://kalev.fedorapeople.org/python-pyside.spec
SRPM URL: http://kalev.fedorapeople.org/python-pyside-0.4.0-2.fc15.src.rpm
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2397329

Comment 8 Chen Lei 2010-08-12 16:55:31 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > FYI, upstream use PySide instead of pyside[1] and fedora naming guideline for
> > python addons also mentions "When in doubt, use the name of the module that you
> > type to import it in a script"[2]
> Depends on where you look. Upstream pages which talk about packaging or repos
> use lower case pyside:
> http://www.pyside.org/downloads/
> http://qt.gitorious.org/pyside/
> Besides that, Fedora Naming Guidelines say:
> "If this package has been packaged by other distributions/packagers in the
> past, then you should try to match their name for consistency."
> so I think it makes sense to follow Debian lead here.    

Though I not consider using python-pyside is agaist fedora naming guideline, I'm pretty sure following debian naming policy[1] is agaist fedora naming guideline[2].
[1]
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source

Package names (both source and binary, see Package, Section 5.6.7) must consist only of lower case letters...

[2]
http://fedoraproject.org/wiki/PackageNamingGuidelines#Case_Sensitivity

Comment 9 Orcan Ogetbil 2010-08-14 18:36:36 UTC
Okay, here is the full review:

* koji scratch build failed
   http://koji.fedoraproject.org/koji/taskinfo?taskID=2401747

! rpmlint says
   python-pyside-devel.x86_64: W: no-documentation
It seems like the directory doc/ contains some developer documentation. No? 
Also the file ChangeLog contains developer oriented information.

* The file PySide/licensecomment.txt should be packaged.

* The source files in libpyside/ are "LGPLv2 with exceptions", however the source files in PySide/ does not specifiy a license in their headers. Please notify upstream. However the file PySide/licensecomment.txt gives us a hint that these files are LGPLv2. So the full license tag should be
   License: LGPLv2 and LGPLv2 with exceptions
Please verify this with upstream and note this in the specfile.

* Patch0:         python-pyside-release-type.patch
Is this a Fedora specific patch? Is it upstreamable?

* The Group tag for the main package should be System Environment/Libraries

! The file
   tests/util/valgrind-python.supp
contains hardcoded /usr/lib/ strings. I don't know if this affects the tests.

* I am also not sure about the naming of the package. The guideline says:
   """There is an exception to this rule. If the upstream source has "py" (or "Py") in its name, you can use that name for the package. So, for example, pygtk is acceptable. """


Note that it says "you can" and not "you should/must". Shall we name the package just PySide? You can add a virtual provides "python-pyside" if you want Debian compatibility. Note also that Debian calls PyQt4 as python-qt4, very strange. There are other naming weirdnesses on Debian too. I think that it is Debian who deviates from upstreams.

! QtMultimedia_audio_test fails. This may be a python-2.7 incompatibility.

   185: Traceback (most recent call last):
   185:   File "/builddir/build/BUILD/pyside-qt4.6+0.4.0/tests/QtMultimedia/audio_test.py", line 30, in testListDevices
   185:     self.assert_(False)
   185: AssertionError: False is not True

! The Phonon test segfaults

   DEBUG: 186: .../builddir/build/BUILD/pyside-qt4.6+0.4.0/tests/run_test.sh: line 13: 29595 Segmentation fault      (core dumped) $3 $4
   DEBUG: 186/189 Test #186: phonon_basic_playing_test .......................***Failed    2.59 sec

I hope this is not significant.

! You don't require pkgconfig. This is fine if this package is Fedora only.

? On the devel package, do we really need
   Requires:       shiboken-devel
I checked the other Requires, and I verified they are all needed, but I can't find the use of this one.

Comment 10 Kalev Lember 2010-08-15 17:26:07 UTC
Thanks for the review, Orcan!

(In reply to comment #9)
> * koji scratch build failed
>    http://koji.fedoraproject.org/koji/taskinfo?taskID=2401747

Yes, as of right now python-pyside is only buildable in rawhide. I'll build the whole pyside stack (apiextractor, generatorrunner, shiboken, python-pyside) in F13 and F14 eventually, but as it needs buildroot overrides, I'll do it once the newly imported package is in rawhide.


> ! rpmlint says
>    python-pyside-devel.x86_64: W: no-documentation
> It seems like the directory doc/ contains some developer documentation. No?
> Also the file ChangeLog contains developer oriented information.

Looks like it needs Qt source tree to generate API documentation. Not sure how to solve this; what do you think? Bundling whole qt tarball with python-pyside source rpm would probably work, but I'm not sure if we want to go down that road.

In any case the docs are also available at  http://www.pyside.org/docs/pyside/


> * The file PySide/licensecomment.txt should be packaged.

Done.


> * The source files in libpyside/ are "LGPLv2 with exceptions", however the
> source files in PySide/ does not specifiy a license in their headers. Please
> notify upstream. However the file PySide/licensecomment.txt gives us a hint
> that these files are LGPLv2. So the full license tag should be
>    License: LGPLv2 and LGPLv2 with exceptions
> Please verify this with upstream and note this in the specfile.

Opened a ticket with upstream bug tracker: http://bugs.openbossa.org/show_bug.cgi?id=297

I'll update the license tag once I get confirmation.


> * Patch0:         python-pyside-release-type.patch
> Is this a Fedora specific patch? Is it upstreamable?

I need to give it some more thought; perhaps we need to change something on Fedora's cmake side instead. In any case, right now I consider this as a Fedora specific patch which makes sure CMake's default -O3 doesn't end up overriding -O2 in $RPM_OPT_FLAGS.


> * The Group tag for the main package should be System Environment/Libraries

I disagree here. Both PyQt4 and pygtk2 use the group Development/Languages.


> ! The file
>    tests/util/valgrind-python.supp
> contains hardcoded /usr/lib/ strings. I don't know if this affects the tests.

Looks like it's a valgrind suppression file for people who want to debug Python in valgrind. At least it doesn't appear to get used during the build.


> * I am also not sure about the naming of the package. The guideline says:
>    """There is an exception to this rule. If the upstream source has "py" (or
> "Py") in its name, you can use that name for the package. So, for example,
> pygtk is acceptable. """

PySide should get Python 3 compatibility very soon now, so we'll most likely end up with separate packages for both Python 2 and Python 3. Fedora Python guidelines require that Python 3 modules need to be prefixed with python3-. I think it looks nicer if the packages are called "python-pyside" and "python3-pyside" as opposed to just plain "pyside" and "python3-pyside".


> Note that it says "you can" and not "you should/must". Shall we name the
> package just PySide? You can add a virtual provides "python-pyside" if you want
> Debian compatibility. Note also that Debian calls PyQt4 as python-qt4, very
> strange. There are other naming weirdnesses on Debian too. I think that it is
> Debian who deviates from upstreams.

In this case, it's _upstream_ that's mostly using the name "python-pyside" in their packaging page: http://www.pyside.org/downloads/
Variations found in this page are:
python-pyside
pyside-qt4
pyside-git

I'd rather pick one from the list above instead of inventing yet another name for Fedora.


> ! QtMultimedia_audio_test fails. This may be a python-2.7 incompatibility.
> 
>    185: Traceback (most recent call last):
>    185:   File
> "/builddir/build/BUILD/pyside-qt4.6+0.4.0/tests/QtMultimedia/audio_test.py",
> line 30, in testListDevices
>    185:     self.assert_(False)
>    185: AssertionError: False is not True

Perhaps; or it might be something that changed in Qt 4.7. On my F-13 machine the very same test dies with an assertion in what appears to be pulseaudio code instead:
python2.6: pcm_params.c:2348: sndrv_pcm_hw_params: Assertion `err >= 0' failed.
/home/kalev/rpmbuild/BUILD/pyside-qt4.6+0.4.0/tests/run_test.sh: line 13: 14050 Aborted                 $3 $4


> ! The Phonon test segfaults
> 
>    DEBUG: 186: .../builddir/build/BUILD/pyside-qt4.6+0.4.0/tests/run_test.sh:
> line 13: 29595 Segmentation fault      (core dumped) $3 $4
>    DEBUG: 186/189 Test #186: phonon_basic_playing_test
> .......................***Failed    2.59 sec
> 
> I hope this is not significant.

It's not showing up in the scratch builds I posted above though. How did you get it to segfault?


> ! You don't require pkgconfig. This is fine if this package is Fedora only.

Yes, it's meant only for Fedora and perhaps EPEL 6 if someone wants to take care of that one day. It's not really buildable on EPEL 4 and 5; Qt just isn't new enough in there.


> ? On the devel package, do we really need
>    Requires:       shiboken-devel
> I checked the other Requires, and I verified they are all needed, but I can't
> find the use of this one.

all the /usr/include/PySide/*/pyside_*_python.h files have:
#include <basewrapper.h>

The file basewrapper.h is from shiboken-devel.

Comment 11 Chen Lei 2010-08-16 01:48:31 UTC
(In reply to comment #10)
> Thanks for the review, Orcan!
> 
 
> > * The Group tag for the main package should be System Environment/Libraries
> 
> I disagree here. Both PyQt4 and pygtk2 use the group Development/Languages.
> 
Actually, python modules should use Development/Libraries, Development/Languages is for python/perl runtime or compiler(e.g. gcc)

> > * I am also not sure about the naming of the package. The guideline says:
> >    """There is an exception to this rule. If the upstream source has "py" (or
> > "Py") in its name, you can use that name for the package. So, for example,
> > pygtk is acceptable. """
> 
> PySide should get Python 3 compatibility very soon now, so we'll most likely
> end up with separate packages for both Python 2 and Python 3. Fedora Python
> guidelines require that Python 3 modules need to be prefixed with python3-. I
> think it looks nicer if the packages are called "python-pyside" and
> "python3-pyside" as opposed to just plain "pyside" and "python3-pyside".
> 
> 
> > Note that it says "you can" and not "you should/must". Shall we name the
> > package just PySide? You can add a virtual provides "python-pyside" if you want
> > Debian compatibility. Note also that Debian calls PyQt4 as python-qt4, very
> > strange. There are other naming weirdnesses on Debian too. I think that it is
> > Debian who deviates from upstreams.
> 
> In this case, it's _upstream_ that's mostly using the name "python-pyside" in
> their packaging page: http://www.pyside.org/downloads/
> Variations found in this page are:
> python-pyside
> pyside-qt4
> pyside-git
> 
python-PySide will be the preferred name for this package since python3 will be supported soon, it'll better to always add python- to upstream name. See https://bugzilla.redhat.com/show_bug.cgi?id=603245#c15 . Following debian naming convention is a bit violation of FPG.

Comment 12 Othman Madjoudj 2010-08-16 02:15:23 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > Thanks for the review, Orcan!
> > 
> 
> > > * The Group tag for the main package should be System Environment/Libraries
> > 
> > I disagree here. Both PyQt4 and pygtk2 use the group Development/Languages.
> > 
> Actually, python modules should use Development/Libraries,
> Development/Languages is for python/perl runtime or compiler(e.g. gcc)
> 

PyQt4
pygtk2
wxPython
tkinter

all use "Development/Languages" group, it's odd!

Comment 13 Chen Lei 2010-08-16 02:28:42 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > Thanks for the review, Orcan!
> > > 
> > 
> > > > * The Group tag for the main package should be System Environment/Libraries
> > > 
> > > I disagree here. Both PyQt4 and pygtk2 use the group Development/Languages.
> > > 
> > Actually, python modules should use Development/Libraries,
> > Development/Languages is for python/perl runtime or compiler(e.g. gcc)
> > 
> 
> PyQt4
> pygtk2
> wxPython
> tkinter
> 
> all use "Development/Languages" group, it's odd!

This is because no guideline in fedora describes the using of those rpm groups, sometimes I'm also confused with which group is the right for my package.

The only docs I found about usage of those groups, I can should Development/Languages is not right for python modules.
http://chorgan.provo.novell.com/susesdk/docs/SUSE%20Package%20Conventions/spc_rpm_groups.html

Comment 14 Kalev Lember 2010-08-16 18:47:59 UTC
Yes, it might very well be that Development/Libraries is technically more correct than Development/Languages, however I'd like to make two points here:
 - Package management tools in Fedora mostly rely on comps instead of rpm groups
 - I prefer consistency over strict rules, especially when the rules are from
   SUSE and the packages we're trying to be consistent with are from Fedora.

Comment 15 Rex Dieter 2010-08-16 19:21:30 UTC
Please don't bikeshed about pkg name and Group.

Group: is largely deprecated and hardly used at all in fedora anymore.   Recent versions of rpm in fedora no longer need it.   For all I care, remove it from the .spec.

name:  I endorse, python-pyside : it offers the best combination of sanity, guidelines conformance, and consistency (with other distros).

Comment 16 Orcan Ogetbil 2010-08-16 20:07:26 UTC
Well, the Group: Development/Languages is just wrong. The fact that other packages make the same mistake does not make this one right. However as you folks said, this tag is not in use in Fedora. Thus this error is not a blocker.

As for the name, the guidelines tell us to use either the tarball name (pyside) or the project name (PySide). Furthermore, if the upstream source has a py or Py in it, you *can* use you can use that name for the package. Since this is a suggestion rather than a restriction, the maintainer is the one to decide. I don't agree with Kalev's decision but I respect it. No blockers from this side either.

Comment 17 Chen Lei 2010-08-17 02:40:54 UTC
Actually, I don't think Group is something we are worth discussing which is almost useless. The fact is both Development/Languages
and Development/Libraries are used in the repo for python modules, see rpm -qg 'groupname' .

For package name, I think we should be more careful, currently python module pkgnames in fedora are just a mess, it's not easy to find requires for a python modules with many dependencies. Keep consistency with other distribution makes sense, however we should not use the same name with them in some circumstance, because debian/ubuntu/arch/gentoo don't allow [A-Z] in pkgname at all.

IMHO, since the upstream name and the namespace(module name) for this package are both PySide, so python-PySide is the most suitable name to match FPG. Actually, we should keep consistency with fedora existed packages over other distributions', now we already have python3-PyQt4 in repo. FYI, some distribution(e.g. mandriva) also use pyside as the pkgname.

From fedora naming guideline:

Packages of python modules (thus they rely on python as a parent) use a slightly different naming scheme. They should take into account the upstream name of the python module. This makes a package name format of python-$NAME. When in doubt, use the name of the module that you type to import it in a script. 

I am adding Toshio to CC for second opinion since the naming for python modules is a bit complicated.

Comment 18 Toshio Ernie Kuratomi 2010-08-17 05:58:18 UTC
Rex is also on the Packaging Committee and I concur with his assessment of the Group and Package Name issues.

When there are several possibilities in the naming guidelines, the maintainer is allowed to choose which one they feel best fits the needs of the package.

Comment 19 Chen Lei 2010-08-17 06:17:33 UTC
Hi all(esp. Rex, Kalev, Oget, Toshio),

It seems our naming policy for python modules is ambiguous and many times I found it's hard to find consistency name for them. I'll suggest to modify Fedora naming guideline slightly refer to the debian python-policy which seems more clear than ours.

See http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html

Public modules used by other packages must have their binary package name prefixed with python-. It is recommended to use this prefix for all packages with public modules as they may be used by other packages in the future. Python 3 modules must be in a separate binary package prefixed with python3- to preserve run time separation between python and python3. The binary package for module foo should preferably be named python-foo, if the module name allows, but this is not required if the binary package ships multiple modules. In the latter case the maintainer chooses the name of the module which represents the package the most. Such a package should support the current Debian Python version, and more if possible (there are several tools to help implement this, see Packaging Tools, Appendix B). For example, if Python 2.3, 2.4, and 2.5 are supported, the Python statement

     import foo

Comment 20 Rex Dieter 2010-08-17 11:52:38 UTC
this kind of commentary is precisely what I asked *not* be done here. :(  offtopic, though *would* make an excellent post for something like fedora-packager list. hint hint. :)

Comment 21 Kalev Lember 2010-09-11 17:50:25 UTC
(In reply to comment #10)
> > * The source files in libpyside/ are "LGPLv2 with exceptions", however the
> > source files in PySide/ does not specifiy a license in their headers. Please
> > notify upstream. However the file PySide/licensecomment.txt gives us a hint
> > that these files are LGPLv2. So the full license tag should be
> >    License: LGPLv2 and LGPLv2 with exceptions
> > Please verify this with upstream and note this in the specfile.
> 
> Opened a ticket with upstream bug tracker:
> http://bugs.openbossa.org/show_bug.cgi?id=297
> 
> I'll update the license tag once I get confirmation.

There is a new 0.4.1 tarball released with the following licensing changes:
 - all the typesystem files now have LGPLv2 license text
 - license was changed from LGPLv2 with exceptions to just plain LGPLv2
 - for the glue files in PySide/ directory the licensecomment.txt applies; the
   glue files are combined together into actual source files and concatenated
   together with the license header in licensecomment.txt file.

Details available at http://bugs.openbossa.org/show_bug.cgi?id=297

Comment 22 Kalev Lember 2010-09-11 18:18:48 UTC
Spec URL: http://kalev.fedorapeople.org/python-pyside.spec
SRPM URL: http://kalev.fedorapeople.org/python-pyside-0.4.1-1.fc15.src.rpm
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2461780

* Sat Sep 11 2010 Kalev Lember <kalev> - 0.4.1-1
- Update to 0.4.1
- Added patch to disable xvfb-run which is currently broken (#632879)
- Disabled phonon bindings (PySide bug #355)
- License change from LGPLv2 with exceptions to LGPLv2

Comment 23 Orcan Ogetbil 2010-09-12 05:29:15 UTC
The package looks good. I would add versioned deps for these 2 libraries
   BuildRequires:  shiboken-devel >= 0.5
   BuildRequires:  qt4-devel >= 4.5.0
as they are both quite recent. I found the numbers in the CMakeLists.txt file.

(In reply to comment #10)
> (In reply to comment #9)
> > ! rpmlint says
> >    python-pyside-devel.x86_64: W: no-documentation
> > Also the file ChangeLog contains developer oriented information.
> 

My above suggestion is still valid.

> > It seems like the directory doc/ contains some developer documentation. No?
> Looks like it needs Qt source tree to generate API documentation. Not sure how
> to solve this; what do you think? Bundling whole qt tarball with python-pyside
> source rpm would probably work, but I'm not sure if we want to go down that
> road.
> 
> In any case the docs are also available at  http://www.pyside.org/docs/pyside/
> 

I couldn't find a way to build the docs without pain either. I guess we need to skip this for now.

> 
> > ! The Phonon test segfaults
> > 
> >    DEBUG: 186: .../builddir/build/BUILD/pyside-qt4.6+0.4.0/tests/run_test.sh:
> > line 13: 29595 Segmentation fault      (core dumped) $3 $4
> >    DEBUG: 186/189 Test #186: phonon_basic_playing_test
> > .......................***Failed    2.59 sec
> > 
> > I hope this is not significant.
> 
> It's not showing up in the scratch builds I posted above though. How did you
> get it to segfault?
> 

I just built it on my local machine. But I can't reproduce it with this last SRPM.

Otherwise everything seems fine. No blockers.

------------------------------------------------
This package (python-pyside) is APPROVED by oget
------------------------------------------------

Comment 24 Chen Lei 2010-09-12 05:56:40 UTC
There are three python bindings available in the pyside site, we should at least propose a consistent naming scheme for those three packages.

pyside-qt4.6+0.4.1.tar.bz2(bindings for qt, namespace PySide)
pyside-mobility-0.1.0.tar.bz2(bindings for qt-mobility, namespace QtMobility)
python-meegotouch-0.1.0.tar.bz2(bindings for libmeegotouch, namespace MeeGo.Touch)

I complain for the naming issue mainly because current fedora infrastructure don't permit to rename a package from little letters to captical letters and vice versa(e.g. We can not rename Zim to zim).

Comment 25 Chen Lei 2010-09-12 06:11:00 UTC
Kalev,

Do you have a idea for the naming scheme of qt-mobility and libmeegotouch python bindings? They will be included in F15 because of meego 1.2 spin, so we need a consistent name for those three python bindings for the same upstream.

Comment 26 Kalev Lember 2010-09-13 14:17:30 UTC
Chen,

I'm not very interested in restarting the bikeshed about naming in this ticket, but perhaps something like this:
python-pyside     (same as Debian's pyside metapackage)
python-qtmobility (Debian is probably going to use this name; talked on IRC
                   with OdyX who handles pyside Debian packages)
python-meegotouch (Debian's probably going for 'python-meego.touch', should be
                   close enough)

Maybe it's something to discuss in the pyside mailing list?

In any case, I'll wait with the SCM request a few days to see if we get some new info about naming.

Comment 27 Chen Lei 2010-09-15 17:28:01 UTC
I have posted a disscusion on python-sig list, I also don't want to waste time on such issue if the current guideline is clear enough.

See http://lists.fedoraproject.org/pipermail/python-devel/2010-September/000283.html


Debian naming policy is a great reference for fedora, however there are two differences in debian naming policy and fedora naming guideline:

1. Fedora pkgname is case sensitive, however debian pkgname must consist only of lower case letters

See http://fedoraproject.org/wiki/PackageNamingGuidelines#Case_Sensitivity
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source

2. '.' is not an acceptable separator for fedora, however '.' is acceptable for debian.

See http://fedoraproject.org/wiki/PackageNamingGuidelines#Separators

Comment 28 Kalev Lember 2010-09-16 15:38:18 UTC
Thanks for your very thorough review, Orcan.

New Package SCM Request
=======================
Package Name: python-pyside
Short Description: Python bindings for Qt4
Owners: kalev rdieter kkofler than ltinkl
Branches: f13 f14
InitialCC:

Comment 29 Kevin Fenzi 2010-09-16 22:59:57 UTC
Git done (by process-git-requests).

Comment 30 Fedora Update System 2010-09-17 19:17:47 UTC
shiboken-0.5.0-2.fc14,generatorrunner-0.6.1-1.fc14,apiextractor-0.8.0-1.fc14,python-pyside-0.4.1-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/shiboken-0.5.0-2.fc14,generatorrunner-0.6.1-1.fc14,apiextractor-0.8.0-1.fc14,python-pyside-0.4.1-2.fc14

Comment 31 Fedora Update System 2010-09-17 19:21:17 UTC
shiboken-0.5.0-2.fc13,generatorrunner-0.6.1-1.fc13,apiextractor-0.8.0-1.fc13,python-pyside-0.4.1-2.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/shiboken-0.5.0-2.fc13,generatorrunner-0.6.1-1.fc13,apiextractor-0.8.0-1.fc13,python-pyside-0.4.1-2.fc13

Comment 32 Fedora Update System 2010-09-20 18:40:31 UTC
shiboken-0.5.0-2.fc14, generatorrunner-0.6.1-1.fc14, apiextractor-0.8.0-1.fc14, python-pyside-0.4.1-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update shiboken generatorrunner apiextractor python-pyside'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/shiboken-0.5.0-2.fc14,generatorrunner-0.6.1-1.fc14,apiextractor-0.8.0-1.fc14,python-pyside-0.4.1-2.fc14

Comment 33 Fedora Update System 2010-09-30 06:12:32 UTC
shiboken-0.5.0-2.fc14, generatorrunner-0.6.1-1.fc14, apiextractor-0.8.0-1.fc14, python-pyside-0.4.1-2.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 34 Fedora Update System 2010-09-30 10:25:49 UTC
shiboken-0.5.0-2.fc13, generatorrunner-0.6.1-1.fc13, apiextractor-0.8.0-1.fc13, python-pyside-0.4.1-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 35 Than Ngo 2013-06-25 09:03:57 UTC
Package Change Request
======================
Package Name: python-pyside
New Branches: el6
Owners: than

Comment 36 Gwyn Ciesla 2013-06-25 11:15:13 UTC
Git done (by process-git-requests).

Comment 37 Jiri Kastner 2014-11-20 13:57:23 UTC
Package Change Request
======================
Package Name: python-pyside
New Branches: epel7
Owners: than jreznik ltinkl kkofler geertj rdieter


Note You need to log in before you can comment on or make changes to this bug.