Sent to sponsors for feedback.

+1

There were some vetos from sponsors, so this will go to the next fesco meeting.

Hopefully some will chime in here with feedback.

Some bugs mentioned:

https://bugzilla.redhat.com/show_bug.cgi?id=575005
https://bugzilla.redhat.com/show_bug.cgi?id=600243
https://bugzilla.redhat.com/show_bug.cgi?id=613881#c5

Replying to [comment:3 kevin]:

There were some vetos from sponsors, so this will go to the next fesco meeting.

Thanks!

Hopefully some will chime in here with feedback.

Some bugs mentioned:

https://bugzilla.redhat.com/show_bug.cgi?id=575005
It's controversial, I already do a lot of search in so called endian-specific data when I perform this review. I found most fedora packages containing endian-specific data store those data to %{_datadir}(e.g. espeak scim-fcitx), actually long-ago debian-dev had a discusiion about espeak, the final conclusion is simply making data subpackage arch-specific instead of noarch, however the data is still located under %{_datadir}.

Currently, FPG don't have a item to mention how to treat large endian-specific files, it'll be better to write a guideline draft if there are some volunteers interested in this.

All in all, the issue for zinnia-tomoe is solved, because zinnia 0.06 use little endian data even under big endian machines.

https://bugzilla.redhat.com/show_bug.cgi?id=600243
Actually, the conflict between libjpeg and libjpeg-turbo is caused by unblocked old libjpeg package in koji[1]. Only five packages will be broken after importing libjpeg-turbo in theory if we don't provide libjpeg in libjpeg-turbo. If I'm already a provenpackager, I can simply commit to those packages instead of leaving them unfixed in koji.

[1]https://bugzilla.redhat.com/show_bug.cgi?id=609366

https://bugzilla.redhat.com/show_bug.cgi?id=613881#c5
This is just an oversight, because I trust srpm/patches from upstream.
https://bugzilla.redhat.com/show_bug.cgi?id=620039#4 and https://bugzilla.rpmfusion.org/show_bug.cgi?id=1224#1 show my understanding with fedora licensing guideline.

Replying to [comment:4 supercyper]:

Currently, FPG don't have a item to mention how to treat large endian-specific files, it'll be better to write a guideline draft if there are some volunteers interested in this.

We already do. It's called "You must obey the FHS". Architecture dependent data cannot go in /usr/share/. The reason for that is that it allows /usr/share to be network mounted between machines of different architectures. So even though the difference between these files was endian-only and not instruction set of the CPUs, it still applied because at the time the program had to have data files that matched the endianness of the CPU. Dennis tried to explain this to you in several comments in the bug.

https://bugzilla.redhat.com/show_bug.cgi?id=613881#c5
This is just an oversight, because I trust srpm/patches from upstream.

Which is something that people shouldn't be doing. The question I would have is: what are you doing to verify licenses since then?

Everybody makes mistakes, even people who have been approved for provenpackagers. The question is really a combination of how much do you already know and also how well do you learn from your mistakes?

Replying to [comment:5 toshio]:

Replying to [comment:4 supercyper]:

Currently, FPG don't have a item to mention how to treat large endian-specific files, it'll be better to write a guideline draft if there are some volunteers interested in this.

We already do. It's called "You must obey the FHS". Architecture dependent data cannot go in /usr/share/. The reason for that is that it allows /usr/share to be network mounted between machines of different architectures. So even though the difference between these files was endian-only and not instruction set of the CPUs, it still applied because at the time the program had to have data files that matched the endianness of the CPU. Dennis tried to explain this to you in several comments in the bug.

I fully agree installing endian-specfic data to %{_datadir} is a violating of FHS and in fact almost all linux distributions claim they obey FHS. So I also suggested to install those data to /usr/lib instead /usr/share in comments. All in all, zinnia-tomoe issues is solved since the zinnia 0.0.6 always use endian-little data even on ppc/sparc. I'd like to start a discuss on -devel/-packaging list later, currently no specfic FPG item is related to this issue and the default installation place for those data are normally /usr/share(maybe most developers are unaware of this issue).

https://bugzilla.redhat.com/show_bug.cgi?id=613881#c5
This is just an oversight, because I trust srpm/patches from upstream.

Which is something that people shouldn't be doing. The question I would have is: what are you doing to verify licenses since then?

Actually, I always check license carefully :) I'm sure I won't have similar issues again. This mistake is made because I trust the srpm from repo.meego.com(this package is a meego-specfic package), so I don't check license at all and modify my spec based on the meego's spec.

About fix FTBTS bugs for fedora:

Currently, I fixed two FTBTS bugs[1][2] for fedora, both of the packages have a lot of dependencies:

[1]qtiplot: https://bugzilla.redhat.com/show_bug.cgi?id=540838
This is also my first package in the fedora, two system libraries are unbudled from qtiplot.

[2]Mayavi: https://bugzilla.redhat.com/show_bug.cgi?id=620068
I help Rakesh to update Mayavi to the latest version which contains sereval dependencies. The original requires for those packages are not suitable for the latest Mayavi, so I also modified requires for Mayavi and its dependencies.

About Meego 1.1 handset/tablet UX packages:
Most of the base packages are submitted for review for several weeks:). I already took a look at all remaining Handset UX packages except some WiMAX packages which I don't have an appropriate network to test them.

Fesco decided to not approve this request at this time.

However, we would urge you to keep working in fedora and reapply at a later date.

Actually, many packagers know me, because I comment frequently on bugzilla, another email for me is supercyper@163.com, supercyper1@gmail.com is for bugzilla/-devel list only. If no one know me, then there is probably no objection on sponsor mail list at all.

I'll appreciate FESCo can forward all negative opinions to me, because no one complains my packages on bugzilla or sends me a private email. It'll be even better that they can communicate to me directly.

The most controversial thing I made is the review of zinnia-tomoe, howerver I'm not approving this package anyway, I comment several choices on the bugzilla.

For the libjpeg-turbo, there are several different ideas on -devel list[1], several people agree with me(e.g the maitainer who is also a provenpackager), it seems my method matches FPG most.
[1]http://lists.fedoraproject.org/pipermail/devel/2010-June/138017.html