[Bug 3110] Deploy the package gstreamer-plugins-bad in EL6 Repository (rpmfusion)
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3110 --- Comment #7 from Simone Caronni negativ...@gmail.com 2014-02-05 10:26:06 CET --- I've prepared the gstreamer-plugins-bad package for el6 basing on your fc12/fc13 package. The only dependency missing in RPMFusion is libmimic, for which I will request CVS access in addition to gstreamer-plugins-bad. I would like also to add the VDPAU plugin, but its place would more appropriately be the main gstreamer-plugins-bad-free package that is in RHEL. This pulls in the following files: /usr/include/gstreamer-0.10/gst/vdpau/gstvdp.h /usr/include/gstreamer-0.10/gst/vdpau/gstvdpdevice.h /usr/include/gstreamer-0.10/gst/vdpau/gstvdpoutputbuffer.h /usr/include/gstreamer-0.10/gst/vdpau/gstvdpoutputsrcpad.h /usr/include/gstreamer-0.10/gst/vdpau/gstvdpvideobuffer.h /usr/include/gstreamer-0.10/gst/vdpau/gstvdpvideosrcpad.h /usr/lib64/libgstvdp-0.10.la /usr/lib64/libgstvdp-0.10.so /usr/lib64/libgstvdp-0.10.so.0 /usr/lib64/libgstvdp-0.10.so.0.0.0 The problem is that el6 devel package by design obsoletes gstreamer-plugins-bad-free-devel: # rpm -qp --provides gstreamer-plugins-bad-free-devel-0.10.19-2.el6.x86_64.rpm gstreamer-plugins-bad-devel = 0.10.19-2.el6 pkgconfig(gstreamer-plugins-bad-0.10) = 0.10.19 gstreamer-plugins-bad-free-devel = 0.10.19-2.el6 gstreamer-plugins-bad-free-devel(x86-64) = 0.10.19-2.el6 Do you think I should skip the VDPAU plugin entirely and simply file a bug upstream to ask for the additon of the plugin to bad-free? Thanks, --Simone -- Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Packaging 3-rd party repositories in rpmfusion
On 02/03/2014 01:07 PM, Alec Leamas wrote: n 2/3/14, Xavier Bachelot xav...@bachelot.org wrote: On 02/03/2014 10:52 AM, Hans de Goede wrote: Hi, On 02/03/2014 02:14 AM, Ralf Corsepius wrote: [2nd attempt to answer to this. My initial response from quite a while age seems to have gone lost.] On 01/29/2014 12:12 PM, Alec Leamas wrote: Formally, this is about review request 3152 for dropbox-repo [1]. From a more practical POV, it's about users being able to install software like dropbox more or less out of the box, an area where I think we really need to improve (as can be seen in all those Fedora XX post installation guide out there). [cut] To handle this, my simple proposal is that we handles packaged yum repositories like this: - It's ok to package yum repositories listed in [4]. - If anyone wants to change the list in [4] this should be announced here on rpmfusion-devel, and not done until we agree on it (similar to how we handle bundling exceptions). Thoughts. out there? All in all, I am not OK with rpmfusion shipping other party's repos, because such repos are out of Fedora's/Rpmfusion's control/influence. They open up an arbitrary amount of opportunities for these 3rd parties to break, corrupt and damage Fedora installations (Package conflicts, low quality packages, malware, spyware, intruded/dead/broken 3rd party servers, etc), without Fedora/RPMfusion being able to do anything against it. Noone is arguing for an arbitrary amount of opportunities , Well, I am. Installation of rpms is performed by root, i.e. package installation is maximum insecure, i.e. allowing any repository an expression of maximum trust to a repository provider by each user. = Any arbitrary repository provider is granted 100% control over a system == an arbitrary amount of opportunities. It's the reason why we tell users to only install from trusted sources (== repositories) and not to pick up random packages from the net. It's one of the key points which had assured safety of Linux over the years and which makes *the* key difference to other OSes (esp. Win and Android). It's this rationale, why I consider adding the idea to add 3rd parties to Fedora or RPMFusion to be a truely stupid idea. This is a valid concern, although I don't think it should be enough to block any packaging attempt. We could change things so that the files are shipped in /usr/whatever and only activated i. e., copied to /etc/yum.repos.d after some kind of dialog where user accepts this (perhaps with a warning text like above). Would this improve the situation? Sightly - It would at least shift responsibility to the user. However it depends much on packaging details. E.g. how do you want to copy with rpm file ownership on files below /etc/yum.repos.d/*.repo and conflicts between such files being shipped by upstream-rpms (rpmfusion, adobe do so), non-rpm-upstreams (e.g. google-chrome does so) and manually written ones. I'm in agreement with Ralf too. imho, one of the biggest selling point for repositories like RPM Fusion is the insurance the Fedora packaging guidelines are enforced and thus the packages will integrate properly with the remaining of the ecosystem. Exactly. It is the selling point and the point behind telling people not to use repositories which do not care about it (e.g. rpmforge or atrpms). From a poilicy point of view current Fedora guidelines on this (which we should comply to ?!) is really more or less a full page about conditions when packaging of external repositories is acceptable or not. Which page are you referring to? One of these recently written pages to embrace 3rd parties? My personal position is clear: A stupid idea, whose only purpose is populism. With my FPC head on: We do not allow 3rd party repos in Fedora, because Fedora can't cope with them on the legal and on the technical sides. In this light, as I understand, RPMFusion is trying to fill this gap. Practically, I feel that some of these arguments seems based on that all external repos are equal. However, they differ a lot. Leaving the list of endorsed repos aside (that list might very well be a Bad Idea anyway), how does these arguments apply the dropbpox repo (which only carries the leaf application dropbox). E. g., what's the risk that this application would destabilize the overall system? As I said before, any arbitrary package has all opportunities to comit any possible kind of damage to your system - The set of possible imaginable scenarios is infinite. Ralf
[Bug 3110] Deploy the package gstreamer-plugins-bad in EL6 Repository (rpmfusion)
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3110 Simone Caronni negativ...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||j.w.r.dego...@gmail.com Resolution|WONTFIX | AssignedTo|j.w.r.dego...@gmail.com |negativ...@gmail.com --- Comment #8 from Simone Caronni negativ...@gmail.com 2014-02-05 11:00:25 CET --- Re-assigning the bug to me. (In reply to comment #0) Is it possible to provide the package gstreamer-plugins-bad in the repository EL6? With this additional package EL6 users are able to use Windows Media streams (mms) and other multimedia in EL6. Thanks a lot! Can you please test it (no VDPAU plugin)? yum install http://slaanesh.fedorapeople.org/el6/gstreamer-plugins-bad-0.10.19-2.el6.x86_64.rpm http://slaanesh.fedorapeople.org/el6/libmimic-1.0.4-7.el6.x86_64.rpm Thanks, --Simone -- Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 3043] Review request: lfp-flash-plugin - Adobe Flash Player package bootstrap
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3043 Simone Caronni negativ...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED -- Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 487] Review request: libmimic - Encoding/decoding library for Mimic V2.x
https://bugzilla.rpmfusion.org/show_bug.cgi?id=487 Simone Caronni negativ...@gmail.com changed: What|Removed |Added CC||negativ...@gmail.com Blocks|4 |33 --- Comment #19 from Simone Caronni negativ...@gmail.com 2014-02-05 14:02:43 CET --- Package Change Request == Package Name: libmimic New Branches: EL-6 Updated RPMFusion Owners: jwrdegoede,slaanesh Updated EPEL Owners: jwrdegoede,slaanesh -- Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 3152] Review request: dropbox-repo - 3rd-party repo package for Dropbox client
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3152
Richard hobbes1...@gmail.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||hobbes1...@gmail.com
Blocks|2 |3
--- Comment #40 from Richard hobbes1...@gmail.com 2014-02-05 19:24:24 CET ---
The only question I could really come up with is if %define is needed for if
%global would work for at the top of the spec file.
Most of the license stuff is moot since you've put it in the Public Domain.
Package Review
==
Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed
= MUST items =
Generic:
[x]: Package is licensed with an open-source compatible license and meets
other legal requirements as defined in the legal section of Packaging
Guidelines.
[-]: If (and only if) the source package includes the text of the license(s)
in its own file, then that file, containing the text of the license(s)
for the package is included in %doc.
[x]: License field in the package spec file matches the actual license.
Note: Checking patched sources after %prep for licenses. No licenses
found. Please check the source files for licenses manually.
Package is in the Public Domain.
[-]: License file installed when any subpackage combination is installed.
[x]: Package must own all directories that it creates.
Note: Directories without known owners: /usr/share/appdata,
/etc/yum.repos.d
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Package is not known to require an ExcludeArch tag.
[-]: Large documentation must go in a -doc subpackage. Large could be size
(~1MB) or number of files.
Note: Documentation size is 20480 bytes in 2 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least one
supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
Note: There are rpmlint messages (see attachment).
[x]: Package requires other packages for directories it uses.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any that
are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
beginning of %install.
[x]: %config files are marked noreplace or the reason is justified.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package contains desktop file if it is a GUI application.
[x]: Package installs a %{name}.desktop using desktop-file-install or desktop-
file-validate if there is such a file.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
work.
[x]: Package is named using only allowed ASCII characters.
[x]: No %config files under /usr.
[x]: Package do not use a name that already exist
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as provided
in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
%{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local
= SHOULD items =
Generic:
[-]: If the source package does not include license text(s) as a separate file
from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Description and summary sections in the package spec file contains
translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
Re: Packaging 3-rd party repositories in rpmfusion
On 2/5/14, Ralf Corsepius ralf.corsep...@gmail.com wrote: On 02/03/2014 01:07 PM, Alec Leamas wrote: n 2/3/14, Xavier Bachelot xav...@bachelot.org wrote: On 02/03/2014 10:52 AM, Hans de Goede wrote: Hi, On 02/03/2014 02:14 AM, Ralf Corsepius wrote: [2nd attempt to answer to this. My initial response from quite a while age seems to have gone lost.] On 01/29/2014 12:12 PM, Alec Leamas wrote: Formally, this is about review request 3152 for dropbox-repo [1]. From a more practical POV, it's about users being able to install software like dropbox more or less out of the box, an area where I think we really need to improve (as can be seen in all those Fedora XX post installation guide out there). [cut] To handle this, my simple proposal is that we handles packaged yum repositories like this: - It's ok to package yum repositories listed in [4]. - If anyone wants to change the list in [4] this should be announced here on rpmfusion-devel, and not done until we agree on it (similar to how we handle bundling exceptions). Thoughts. out there? All in all, I am not OK with rpmfusion shipping other party's repos, because such repos are out of Fedora's/Rpmfusion's control/influence. They open up an arbitrary amount of opportunities for these 3rd parties to break, corrupt and damage Fedora installations (Package conflicts, low quality packages, malware, spyware, intruded/dead/broken 3rd party servers, etc), without Fedora/RPMfusion being able to do anything against it. Noone is arguing for an arbitrary amount of opportunities , Well, I am. Installation of rpms is performed by root, i.e. package installation is maximum insecure, i.e. allowing any repository an expression of maximum trust to a repository provider by each user. = Any arbitrary repository provider is granted 100% control over a system == an arbitrary amount of opportunities. It's the reason why we tell users to only install from trusted sources (== repositories) and not to pick up random packages from the net. It's one of the key points which had assured safety of Linux over the years and which makes *the* key difference to other OSes (esp. Win and Android). Agreed. But we are not talking about random packages from the net. We are talking about making it easy to install specific apps from some selected repos. It's this rationale, why I consider adding the idea to add 3rd parties to Fedora or RPMFusion to be a truely stupid idea. Could you not at least agree on that we actually have a trade-off here? Many (most? almost all?) fedora/rpmfusion users want to use some apps available from 3-rd party repos for various reasons. Not supporting this at all forces them to apply random guides out there, with all sorts of risks and problems. Supporting it also carries risks, agreed. But I just don't think it's fair to call any position about this stupid. This is a valid concern, although I don't think it should be enough to block any packaging attempt. We could change things so that the files are shipped in /usr/whatever and only activated i. e., copied to /etc/yum.repos.d after some kind of dialog where user accepts this (perhaps with a warning text like above). Would this improve the situation? Sightly - It would at least shift responsibility to the user. As of today, user will face the dialog in [1]. This would IMHO make user responsible. However it depends much on packaging details. E.g. how do you want to copy with rpm file ownership on files below /etc/yum.repos.d/*.repo and conflicts between such files being shipped by upstream-rpms (rpmfusion, adobe do so), non-rpm-upstreams (e.g. google-chrome does so) and manually written ones. As for dropbox-repo, the repo file is in a sub-package. The main package requires the repo file directly. The result is that it will use an already existing repo file without conflicts, more or less just adding some metadata to it. From a poilicy point of view current Fedora guidelines on this (which we should comply to ?!) is really more or less a full page about conditions when packaging of external repositories is acceptable or not. Which page are you referring to? One of these recently written pages to embrace 3rd parties? My personal position is clear: A stupid idea, whose only purpose is populism. If populism is about making Fedora/rpmfusion a popular distribution, then call me a populist. I can live with that. With my FPC head on: We do not allow 3rd party repos in Fedora, because Fedora can't cope with them on the legal and on the technical sides. Reading current GL I cannot interpret them as a plain We do not allow 3rd party repos in Fedora. If the rule was that simple, why a full page of text with different cases? From a technical POV, I cannot see the difficulties in adding a repo file. Am I missing something here? That said, of course much of these GL is about legal issues. As this is where rpmfusion really differs, we certainly need to
