[Bug 1627084] New: Review Request:
mutter328 - Window and compositing manager based on Clutter
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1627084
Bug ID: 1627084
Summary: Review Request: mutter328 - Window and compositing
manager based on Clutter
Product: Fedora
Version: rawhide
Component: Package Review
Severity: medium
Priority: medium
Assignee: nobody(a)fedoraproject.org
Reporter: decathorpe(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: package-review(a)lists.fedoraproject.org
Spec URL: https://decathorpe.fedorapeople.org/packages/mutter328.spec
SRPM URL:
https://decathorpe.fedorapeople.org/packages/mutter328-3.28.3-4.fc28.src.rpm
Description:
============
Mutter is a window and compositing manager that displays and manages
your desktop via OpenGL. Mutter combines a sophisticated display engine
using the Clutter toolkit with solid window-management logic inherited
from the Metacity window manager.
While Mutter can be used stand-alone, it is primarily intended to be
used as the display core of a larger system such as GNOME Shell. For
this reason, Mutter is very extensible via plugins, which are used both
to add fancy visual effects and to rework the window management
behaviors to meet the needs of the environment.
Fedora Account System Username: decathorpe
koji scratch build for rawhide:
https://koji.fedoraproject.org/koji/taskinfo?taskID=29597663
Packager's Notes:
=================
This package is based on the f28 branch of the main mutter package, and has
been cleaned up for best practices and new Guidelines. The package is needed as
a compat package for gala, wingpanel, and future versions pantheon-greeter due
to an API and ABI bump in mutter with versions 3.29.4+ (libmutter-2 ->
libmutter-3).
In addition, I've added Conflicts tags to the packages where they conflict with
the main mutter package. It looks like gala does not require any of mutter's
data files to be present, but only requires the shared libraries (and possibly
GSettings keys, etc.) - that's why I split them out into a new -libs
sub-package. It boils down to this:
- mutter328-devel is only needed as BuildRequires for gala and
pantheon-greeter. This package is not parallel-installable with mutter-devel
3.30 in f29 and rawhide (this is expected).
- mutter328-libs is only needed as runtime requirement of gala, wingpanel, and
pantheon-greeter. This package is parallel-installable with mutter 3.30 in f29
and rawhide, and depends on the main mutter package for the data files (e.g.
GSettings schemas).
- mutter328 and mutter328-tests are expected to conflict with the main mutter
package, and should never be installed manually (and should not be pulled in as
dependencies automatically).
I checked that this works as expected with rebuilt packages from my COPR
repositories (decathorpe/elementary-staging for stable builds,
decathorpe/elementary-nightly for builds from git master).
--
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
5 years, 8 months
[Bug 1501522] Review Request:
fdk-aac - Third-Party Modified Version of the Fraunhofer FDK AAC Codec
Library for Android
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1501522
--- Comment #98 from Christian Fredrik Kalager Schaller <cschalle(a)redhat.com> ---
(In reply to Nicolas Chauvet (kwizart) from comment #97)
> (In reply to Wim Taymans from comment #95)
> ...
> > Can you re-approve the bug again?
> Once again. I would not approve this unless the package is named
> fdk-aac-free to denote the incompleteness of the library (possibly with a
> virtual provide fdk-aac).
I see people make a big issue of this on this thread, but do you actually have
a real world file that gives you problems? Or are you tilting at windmills
here?
> If that can be done, both fedora fdk-aac-free and rpmfusion fdk-aac-free
> would use a normal packaging method. (and they would conflicts).
>
> For users, it would only be a matter to replace the former with the latter.
Ok, so you want the package to be called -free at the end, but no changes to
the .so file names etc., right?
> But you need to provide a bug-free fdk-aac implementation. It's not at all
> acceptable that have unfixable items on the fedora side that would only be
> fixed by using the fully implemented version.
What do you mean with a 'bug free' implementation?
> Please also reminds that rpmfusion has version 1.6 since fc28 and I don't
> see that would have updated the fedora counterpart in time. This is a
> problem for us.
> To me, it means there is a need for a new legal review for each library
> update.
The only reason the package didn't get updated is due to the quagmire of this
bugreport.
--
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
5 years, 8 months
[Bug 1501522] Review Request:
fdk-aac - Third-Party Modified Version of the Fraunhofer FDK AAC Codec
Library for Android
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1501522
--- Comment #97 from Nicolas Chauvet (kwizart) <kwizart(a)gmail.com> ---
(In reply to Wim Taymans from comment #95)
...
> Can you re-approve the bug again?
Once again. I would not approve this unless the package is named fdk-aac-free
to denote the incompleteness of the library (possibly with a virtual provide
fdk-aac).
If that can be done, both fedora fdk-aac-free and rpmfusion fdk-aac-free would
use a normal packaging method. (and they would conflicts).
For users, it would only be a matter to replace the former with the latter.
But you need to provide a bug-free fdk-aac implementation. It's not at all
acceptable that have unfixable items on the fedora side that would only be
fixed by using the fully implemented version.
Please also reminds that rpmfusion has version 1.6 since fc28 and I don't see
that would have updated the fedora counterpart in time. This is a problem for
us.
To me, it means there is a need for a new legal review for each library update.
--
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
5 years, 8 months