Re: wl-kmod for F-18
Le mardi 22 octobre 2013 à 15:19 +0200, Nicolas Viéville a écrit : It was just pushed. As it's the latest, please submit a new job, the root cause of this is still unknown It happened again this morning with wl-kmod for F-18. This time it was a mock error. I have a question. If I submit a new job, I'll probably have to change the minor release version number to be able to do so. Isn't it annoying and wouldn't it be more appropriate to just ask plague to requeue this job and keep this minor release version tag unchanged, since nothing is changed in the package and it is simply rebuilt? Thanks in advance for your explanations about this. Cordially, To be complete the log message found there: http://buildsys.rpmfusion.org/logs/fedora-18-rpmfusion_nonfree/18751-wl-kmod-6.30.223.141-1.fc18.5/x86_64/job.log says: Job failed because it was killed. -- NVieville
[Bug 2979] Review request: steam - Installer for the Steam software distribution service
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2979
--- Comment #27 from MartinKG mgans...@alice.de 2013-10-23 08:32:09 CEST ---
package steam contains desktop file(s) with a MimeType: entry.
please update-desktop-database in spec file
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#desktop-database
%post
/usr/bin/update-mime-database %{_datadir}/mime /dev/null || :
%postun
/usr/bin/update-mime-database %{_datadir}/mime /dev/null || :
--
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.
You are the assignee for the bug.
[Bug 2979] Review request: steam - Installer for the Steam software distribution service
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2979
--- Comment #28 from Simone Caronni negativ...@gmail.com 2013-10-23 09:57:37
CEST ---
(In reply to comment #27)
package steam contains desktop file(s) with a MimeType: entry.
please update-desktop-database in spec file
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#desktop-database
Done.
%post
/usr/bin/update-mime-database %{_datadir}/mime /dev/null || :
%postun
/usr/bin/update-mime-database %{_datadir}/mime /dev/null || :
Please note that this is for mimeinfo
(http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#mimeinfo) and not
for desktop-database, probably a copy paste error.
Spec URL: http://slaanesh.fedorapeople.org/steam.spec
SRPM URL: http://slaanesh.fedorapeople.org/steam-1.0.0.43-5.fc19.src.rpm
- Added desktop-database commands in %post/%postun
- Removed removal of buildroot in %install
--
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.
You are the assignee for the bug.
Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On 10/22/2013 11:27 AM, Xavier Bachelot wrote: On 10/15/2013 10:13 AM, Xavier Bachelot wrote: ECC seems to be allowed in Fedora now. I've filled a bug against libgcrypt requesting to enable it : https://bugzilla.redhat.com/show_bug.cgi?id=1019126 Once this is done, the libgcrypt-freeworld will become useless. ECC-enabled libgcrypt is now available in Koji : https://admin.fedoraproject.org/updates/libgcrypt-1.5.3-2.fc19 https://admin.fedoraproject.org/updates/libgcrypt-1.5.3-2.fc20 Not tested yet, I will test and give karma this evening. Tested OK and karma given. A major roadblock has been removed, enjoy :-) Xavier
[Bug 2857] Review request: xine-lib 1.2 - A multimedia engine
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2857 --- Comment #14 from Xavier Bachelot xav...@bachelot.org 2013-10-23 11:26:30 CEST --- No answer from Martin Sourada yet, but we need to move forward in order to be ready for F20 Beta (2013-10-29). Package CVS request == Package Name: gxine Short Description: GTK frontend for the xine multimedia library Owners: xavierb,sundaram Branches: f20 InitialCC: -- License tag: free Package CVS request == Package Name: xine-plugin Short Description: Mozilla/Netscape compatible media plugin Owners: xavierb Branches: f20 InitialCC: -- 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: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs
On Wed, Oct 23, 2013 at 4:16 AM, Xavier Bachelot xav...@bachelot.orgwrote: Tested OK and karma given. A major roadblock has been removed, enjoy :-) Awesome! Thanks, Richard
[Bug 2979] Review request: steam - Installer for the Steam software distribution service
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2979
Simone Caronni negativ...@gmail.com changed:
What|Removed |Added
Blocks|2 |3
AssignedTo|rpmfusion-package-review@rp |leamas.a...@gmail.com
|mfusion.org |
--- Comment #29 from Simone Caronni negativ...@gmail.com 2013-10-23 15:03:33
CEST ---
Issues:
[!]: Useful -debuginfo package or justification otherwise.
Disabling debuginfo is fine here, but needs a justification comment.
[!]: Requires correct, justified where necessary.
[!]: Package must own all directories that it creates.
/usr/lib/udev and /usr/lib/udev/rules.d are owned by systemd,
/etc/profile.d by setup. These need to be Require:'d.
[!]: Package contains no bundled libraries without FPC exception.
The bundled libraries need to be in package according to the license.
Still, they need a bundling exception. Request on rpmfusion-developers.
[!]: Valid rpmlint warnings, please fix:
name-repeated-in-summary C Steam
wrong-file-end-of-line-encoding
/usr/share/doc/steam/steam_install_agreement.txt
steam.src:35: W: macro-in-comment %{name}
steam.src:36: W: macro-in-comment %{_isa}
[!]: Package is licensed with an open-source compatible license and meets
other legal requirements as defined in the legal section of Packaging
Guidelines.
--OK for rpmfusion, though. Please add some kind of reference to
the license in a comment above it.
--
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.
You are the assignee for the bug.
[Bug 2979] Review request: steam - Installer for the Steam software distribution service
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2979
--- Comment #31 from Simone Caronni negativ...@gmail.com 2013-10-23 15:27:17
CEST ---
(In reply to comment #29)
Issues:
[!]: Useful -debuginfo package or justification otherwise.
Disabling debuginfo is fine here, but needs a justification comment.
Added comment.
[!]: Requires correct, justified where necessary.
[!]: Package must own all directories that it creates.
/usr/lib/udev and /usr/lib/udev/rules.d are owned by systemd,
/etc/profile.d by setup. These need to be Require:'d.
I've added them as BuildRequirements so I can avoid the mkdir -p commands;
the folder is already available at build time and I can just copy the files
into them.
Adding them as Requirement is not required as setup and systemd are already
pulled in by other packages.
wrong-file-end-of-line-encoding
/usr/share/doc/steam/steam_install_agreement.txt
Done, did as packaging guidelines suggested and removed dos2unix
(https://fedoraproject.org/wiki/Common_Rpmlint_issues#wrong-file-end-of-line-encoding).
steam.src:35: W: macro-in-comment %{name}
steam.src:36: W: macro-in-comment %{_isa}
Fixed, escaped them (%%).
[!]: Package is licensed with an open-source compatible license and meets
other legal requirements as defined in the legal section of Packaging
Guidelines.
--OK for rpmfusion, though. Please add some kind of reference to
the license in a comment above it.
Done, added a comment.
--
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 2979] Review request: steam - Installer for the Steam software distribution service
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2979 --- Comment #32 from Simone Caronni negativ...@gmail.com 2013-10-23 15:31:58 CEST --- Spec URL: http://slaanesh.fedorapeople.org/steam.spec SRPM URL: http://slaanesh.fedorapeople.org/steam-1.0.0.43-6.fc19.src.rpm Added all changes except this: [!]: Valid rpmlint warnings, please fix: name-repeated-in-summary C Steam I've taken the description from their official deb package, I think it's pretty good. Any idea on how can I remove the Steam word if the word SteamCloud stays there? Also Steam software distribution service IMHO should remain as is. Ideas? (personally I think this rpmlint check is quite stupid, it causes more confusing description than anything else) -- 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 2842] Review request: openssl-freeworld - Utilities from the general purpose cryptography library with TLS implementation
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2842 Frank Ch. Eigler f...@redhat.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|EXPIRED | --- Comment #7 from Frank Ch. Eigler f...@redhat.com 2013-10-23 15:58:59 CEST --- It appears as though the newest fedora libraries are still somewhat hobbled (only a few selected EC curves enabled?), so that a -freeworld build would still be helpful. -- 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. You are the assignee for the bug.
[Bug 30] Tracker : Sponsorship Request
https://bugzilla.rpmfusion.org/show_bug.cgi?id=30 Bug 30 depends on bug 2842, which changed state. Bug 2842 Summary: Review request: openssl-freeworld - Utilities from the general purpose cryptography library with TLS implementation https://bugzilla.rpmfusion.org/show_bug.cgi?id=2842 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|EXPIRED | -- Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 2979] Review request: steam - Installer for the Steam software distribution service
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2979
--- Comment #34 from Simone Caronni negativ...@gmail.com 2013-10-23 16:02:13
CEST ---
Alec Leamas wrote:
Looks fine. Two more issues:
- In the README.fedora you refer to
http://slaanesh.fedorapeople.org/flash-plugin/README.txt. This doesn't seemt
to exist.
- You run %{_bindir}/update-desktop-database /dev/null || : only if [ $1
-eq 0 ]. This is not as proposed in the standard packaging scriptlets where
it's run unconditionally [1]. Please fix or justify current code.
[1] http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#desktop-database
We continue as normal: : you paste the remarks in the bug
While you're on it: if other packages pulls systemd, why list systemd-libs?
Thanks, adjusted them all. Systemd-libs is pulled in by mesa and a lot of other
things.
Still at revision 6:
Spec URL: http://slaanesh.fedorapeople.org/steam.spec
SRPM URL: http://slaanesh.fedorapeople.org/steam-1.0.0.43-6.fc19.src.rpm
--
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.
RPM Fusion (Fedora - free) Package Build Report 2013-10-23
Packages built and released for RPM Fusion (Fedora - free) 19: 10 ffmpeg-1.2.4-2.fc19 ndiswrapper-kmod-1.58-6.fc19.5 ndiswrapper-kmod-1.58-6.fc19.6 openafs-kmod-1.6.5.1-1.fc19.1 openafs-kmod-1.6.5.1-1.fc19.2 staging-kmod-3.11.1-1.fc19.6 staging-kmod-3.11.1-1.fc19.7 VirtualBox-kmod-4.2.18-2.fc19.4 VirtualBox-kmod-4.2.18-2.fc19.5 xtables-addons-kmod-2.3-3.fc19.16 Packages built and released for RPM Fusion (Fedora - free) testing/19: 2 fceux-2.2.2-2.fc19 xtables-addons-kmod-2.3-3.fc19.17 Packages built and released for RPM Fusion (Fedora - free) testing/18: 1 fceux-2.2.2-2.fc18 Packages built and released for RPM Fusion (Fedora - free) development: 1 fceux-2.2.2-2.fc20 Changes in RPM Fusion (Fedora - free) 19: ffmpeg-1.2.4-2.fc19 --- * Wed Oct 16 2013 Julian Sikorski beleg...@fedoraproject.org - 1.2.4-2 - Enabled avresample ndiswrapper-kmod-1.58-6.fc19.5 -- * Mon Oct 14 2013 Nicolas Chauvet kwiz...@gmail.com - 1.58-6.5 - Rebuilt for kernel ndiswrapper-kmod-1.58-6.fc19.6 -- * Tue Oct 22 2013 Nicolas Chauvet kwiz...@gmail.com - 1.58-6.6 - Rebuilt for kernel * Mon Oct 14 2013 Nicolas Chauvet kwiz...@gmail.com - 1.58-6.5 - Rebuilt for kernel openafs-kmod-1.6.5.1-1.fc19.1 - * Mon Oct 14 2013 Nicolas Chauvet kwiz...@gmail.com - 1.6.5.1-1.1 - Rebuilt for kernel openafs-kmod-1.6.5.1-1.fc19.2 - * Tue Oct 22 2013 Nicolas Chauvet kwiz...@gmail.com - 1.6.5.1-1.2 - Rebuilt for kernel staging-kmod-3.11.1-1.fc19.6 * Mon Oct 14 2013 Nicolas Chauvet kwiz...@gmail.com - 3.11.1-1.6 - Rebuilt for kernel staging-kmod-3.11.1-1.fc19.7 * Tue Oct 22 2013 Nicolas Chauvet kwiz...@gmail.com - 3.11.1-1.7 - Rebuilt for kernel VirtualBox-kmod-4.2.18-2.fc19.4 --- * Mon Oct 14 2013 Nicolas Chauvet kwiz...@gmail.com - 4.2.18-2.4 - Rebuilt for kernel VirtualBox-kmod-4.2.18-2.fc19.5 --- * Tue Oct 22 2013 Nicolas Chauvet kwiz...@gmail.com - 4.2.18-2.5 - Rebuilt for kernel * Mon Oct 14 2013 Nicolas Chauvet kwiz...@gmail.com - 4.2.18-2.4 - Rebuilt for kernel xtables-addons-kmod-2.3-3.fc19.16 - * Mon Oct 14 2013 Nicolas Chauvet kwiz...@gmail.com - 2.3-3.16 - Rebuilt for kernel Changes in RPM Fusion (Fedora - free) testing/19: fceux-2.2.2-2.fc19 -- * Wed Oct 23 2013 Andrea Musuruane musur...@gmail.com - 2.2.2-2 - Added missing update of desktop database xtables-addons-kmod-2.3-3.fc19.17 - * Tue Oct 22 2013 Nicolas Chauvet kwiz...@gmail.com - 2.3-3.17 - Rebuilt for kernel Changes in RPM Fusion (Fedora - free) testing/18: fceux-2.2.2-2.fc18 -- * Wed Oct 23 2013 Andrea Musuruane musur...@gmail.com - 2.2.2-2 - Added missing update of desktop database Changes in RPM Fusion (Fedora - free) development: fceux-2.2.2-2.fc20 -- * Wed Oct 23 2013 Andrea Musuruane musur...@gmail.com - 2.2.2-2 - Added missing update of desktop database
RPM Fusion (Fedora - nonfree) Package Build Report 2013-10-23
Packages built and released for RPM Fusion (Fedora - nonfree) 19: 11 catalyst-kmod-13.9-2.fc19.2 catalyst-kmod-13.9-2.fc19.3 nvidia-173xx-kmod-173.14.38-1.fc19.4 nvidia-173xx-kmod-173.14.38-1.fc19.5 nvidia-304xx-kmod-304.108-1.fc19.4 nvidia-304xx-kmod-304.108-1.fc19.5 nvidia-kmod-325.15-1.fc19.4 nvidia-kmod-325.15-1.fc19.5 NEW perl-PGPLOT-2.21-2.fc19 : Perl extension for using the pgplot library wl-kmod-6.30.223.141-1.fc19.5 wl-kmod-6.30.223.141-1.fc19.6 Changes in RPM Fusion (Fedora - nonfree) 19: catalyst-kmod-13.9-2.fc19.2 --- * Mon Oct 14 2013 Nicolas Chauvet kwiz...@gmail.com - 13.9-2.2 - Rebuilt for kernel catalyst-kmod-13.9-2.fc19.3 --- * Tue Oct 22 2013 Nicolas Chauvet kwiz...@gmail.com - 13.9-2.3 - Rebuilt for kernel * Mon Oct 14 2013 Nicolas Chauvet kwiz...@gmail.com - 13.9-2.2 - Rebuilt for kernel nvidia-173xx-kmod-173.14.38-1.fc19.4 * Mon Oct 14 2013 Nicolas Chauvet kwiz...@gmail.com - 173.14.38-1.4 - Rebuilt for kernel nvidia-173xx-kmod-173.14.38-1.fc19.5 * Tue Oct 22 2013 Nicolas Chauvet kwiz...@gmail.com - 173.14.38-1.5 - Rebuilt for kernel nvidia-304xx-kmod-304.108-1.fc19.4 -- * Mon Oct 14 2013 Nicolas Chauvet kwiz...@gmail.com - 304.108-1.4 - Rebuilt for kernel nvidia-304xx-kmod-304.108-1.fc19.5 -- * Tue Oct 22 2013 Nicolas Chauvet kwiz...@gmail.com - 304.108-1.5 - Rebuilt for kernel nvidia-kmod-325.15-1.fc19.4 --- * Mon Oct 14 2013 Nicolas Chauvet kwiz...@gmail.com - 1:325.15-1.4 - Rebuilt for kernel nvidia-kmod-325.15-1.fc19.5 --- * Tue Oct 22 2013 Nicolas Chauvet kwiz...@gmail.com - 1:325.15-1.5 - Rebuilt for kernel perl-PGPLOT-2.21-2.fc19 --- * Wed Sep 11 2013 Sergio Pascual sergi...@fis.ucm.es - 2.21-2 - Removed patch - Added buildrequires perl(ExtUtils::F77) wl-kmod-6.30.223.141-1.fc19.5 - * Mon Oct 14 2013 Nicolas Chauvet kwiz...@gmail.com - 6.30.223.141-1.5 - Rebuilt for kernel wl-kmod-6.30.223.141-1.fc19.6 - * Tue Oct 22 2013 Nicolas Chauvet kwiz...@gmail.com - 6.30.223.141-1.6 - Rebuilt for kernel
[Bug 2909] Review request: gtkradiant - Level design program for video games
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2909 --- Comment #3 from Alberto bebo.s...@gmail.com 2013-10-23 16:17:09 CEST --- Hi all, I wrote again to Gtkradiant ML about the permission errors[1] but the upstream doesn't want to solve this problem, due to an enormous work in the code, which obviously they don't want to do. A friend of mine helped me to patch the code to read and write the code in the hidden folder ~/.radiant/. Now the the exec reads the sdk(s) from the folder above and at the startup the data has to be in the user folder, so I'm going to create a script to do this. I will also split the sdk-data in another package, to manage them better. Alberto [1]: http://icculus.org/pipermail/gtkradiant/2013-September/011887.html -- 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. You are the assignee for the bug.
[Bug 2909] Review request: gtkradiant - Level design program for video games
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2909 --- Comment #4 from Alberto bebo.s...@gmail.com 2013-10-23 16:20:17 CEST --- Created attachment 1197 -- https://bugzilla.rpmfusion.org/attachment.cgi?id=1197 allow the use of gtkradiant in linux -- 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. You are the assignee for the bug.
[Bug 2857] Review request: xine-lib 1.2 - A multimedia engine
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2857 --- Comment #15 from Xavier Bachelot xav...@bachelot.org 2013-10-23 18:36:54 CEST --- I just got an answer from Martin, so here's an updated CVS request, please discard the one from comment 14. Please note Martin Sourada (username mso) needs to be approved in CVS extras group. Package CVS request == Package Name: gxine Short Description: GTK frontend for the xine multimedia library Owners: mso,sundaram,xavierb Branches: f20 InitialCC: -- License tag: free Package CVS request == Package Name: xine-plugin Short Description: Mozilla/Netscape compatible media plugin Owners: mso,xavierb Branches: f20 InitialCC: -- 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.
i686 binary packages in the x86_64 repository
Hello, the Steam review has been taken, however the reviewer wonders if the infrastructure can cope with i686 binary packages being pushed to the x86_64 repository. I thought it was possible, but this is my first review in RPMFusion so I don't know details of the infrastructure. When installing in a x86_64 system, the package pulls in the correct 32 bit dependencies. Currently I'm using Steam with 65 games on a 64 bit Fedora 19 host. The same package is the currently suggested one [1] from Valve for running Steam on both i386 and x86_64 hosts. The package was created by me and adjusted based on feedback from the Steam community forum with users providing additional information and testing pulling from my personal repository page [2]. In fact, 99% of the users run a 64 bit distribution. It would be a shame not to see this appear in RPMFusion just for a limit of the infrastructure. Can the i686 be pushed also to the x86_64 repository once reviewed? Thanks regards, --Simone [1] https://developer.valvesoftware.com/wiki/Steam_under_Linux#Fedora [2] http://negativo17.org/steam/ -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/
CDRtools in RPMFusion
Hello, I would like to merge my current CDRtools package [1] in RPMFusion. It currently has quite a large user base. It is used by people who needs to burn Dual Layer DVDs or Blue Ray discs. Currently cdrkit (wodim) is not able to burn them; actually it never had since its first exception. I would like to push the package in both Fedora and EPEL branches; as my package currently works with both. It's also using kernel capabilities in both EPEL 6+ and Fedora; so that's a nice addition to avoid SUID binaries. In its current form it simply replaces wodim and all the other cdrkit packages, so I understand it does not fit in the current RPMFusion policies for package inclusion. I was thinking to adjust it and submit a review. Cdrkit currently ships with alternatives configured for readcd, cdrecord and mkisofs. The idea is to add a package for shipping those as alternatives for cdrkit with a higher priority. This way, a user who wants to install cdrecord would have the symlink correctly configured with it as the preference; the package would not overwrite base packages and there's no configuration required. And users who don't know what is it, would not get the package. There are a few issues though: - Cdrkit ships symlinks for some of the programs, not all (i.e. isoinfo, isovfy, etc.); a bug needs to be opened on cdrkit in Fedora. - Cdrtools binaries would have weird names on the system (like cdrtools.cdrecord or cdrtools.mkisofs), but alternatives would return the correct name. - The package gets really complicated for nothing. - The same cdrkit package shipped in RHEL 6 uses the same alternatives, and bugs in bugzilla gets usually ignored. - The RHEL 5 package can't be updated, as it already ships cdrecord, etc. I think there would be some interest into shipping it in RPMFusion, at least for EPEL 6 and Fedora; what is your idea? Should I proceed into the long process of fixing packages upstream and then publish the review? I have a Redhat account as a customer, so I can probably also file bugs for RHEL 6 cdrkit packages, but I don't know about the results. Thanks regards, --Simone [1] http://negativo17.org/cdrtools/ -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/
Re: i686 binary packages in the x86_64 repository
On 2013-10-23 19:22, Simone Caronni wrote: Hello, the Steam review has been taken, however the reviewer wonders if the infrastructure can cope with i686 binary packages being pushed to the x86_64 repository. I thought it was possible, but this is my first review in RPMFusion so I don't know details of the infrastructure. When installing in a x86_64 system, the package pulls in the correct 32 bit dependencies. Currently I'm using Steam with 65 games on a 64 bit Fedora 19 host. The same package is the currently suggested one [1] from Valve for running Steam on both i386 and x86_64 hosts. The package was created by me and adjusted based on feedback from the Steam community forum with users providing additional information and testing pulling from my personal repository page [2]. In fact, 99% of the users run a 64 bit distribution. It would be a shame not to see this appear in RPMFusion just for a limit of the infrastructure. Can the i686 be pushed also to the x86_64 repository once reviewed? Thanks regards, I wonder if the simple answer is just No, you can't . OTOH, isn't it perfectly viable to install a 32-bit package on a x86_64 host using e. g., yum install steam.i386? If that is seen as a little awkward, one could probably create subpackages with correct architecture which pulls in steam.i386 (?) --alec
Re: i686 binary packages in the x86_64 repository
On 23 October 2013 19:58, Alec Leamas leamas.a...@gmail.com wrote: On 2013-10-23 19:22, Simone Caronni wrote: I wonder if the simple answer is just No, you can't . OTOH, isn't it perfectly viable to install a 32-bit package on a x86_64 host using e. g., yum install steam.i386? It can be done, but installing it by calling steam.i686 or just steam is the same if the i686 package is the only one in the repository. It's managed by yum, ff there's the native arch package, that is pulled in, otherwise the compatible others. Actually, if you run my repository on x86_64 and issue a yum install steam the steam.i686 package is installed. If that is seen as a little awkward, one could probably create subpackages with correct architecture which pulls in steam.i386 (?) Creating a 64 bit steam package, with all libraries and programs written in as library(x86-32) in the requirements is a really ugly hack... I would rather not do it. On top of this, after installing the Steam client, there are hints (libraries, a stub Ubuntu runtime, etc.) that the client will sooner or later ported to 64 bit (maybe in the new SteamMachines?); so creating a package like that would create a lot of mess. Example: [slaanesh@3zpc0560 Steam]$ ls -ald ubuntu12_* drwx--. 2 slaanesh slaanesh 4096 Oct 20 19:57 ubuntu12_32 drwxrwxr-x. 2 slaanesh slaanesh 4096 Oct 10 23:37 ubuntu12_64 [slaanesh@3zpc0560 Steam]$ ls -al ubuntu12_64/ total 15460 drwxrwxr-x. 2 slaanesh slaanesh 4096 Oct 10 23:37 . drwx--. 26 slaanesh slaanesh 4096 Oct 23 16:37 .. -rwxrwxr-x. 1 slaanesh slaanesh 472576 Oct 4 02:47 crashhandler.so -rwxrwxr-x. 1 slaanesh slaanesh 173323 Sep 27 19:57 gameoverlayrenderer.so -rwxrwxr-x. 1 slaanesh slaanesh 191997 Sep 25 23:57 libtier0_s.so -rwxrwxr-x. 1 slaanesh slaanesh 235937 Oct 4 02:47 libvstdlib_s.so -rwxrwxr-x. 1 slaanesh slaanesh 14739300 Oct 9 04:25 steamclient.so [slaanesh@3zpc0560 Steam]$ ldd ubuntu12_64/steamclient.so linux-vdso.so.1 = (0x7fff6673c000) [...] libstdc++.so.6 = /lib64/libstdc++.so.6 (0x7f1d8cbb3000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f1d8c997000) /lib64/ld-linux-x86-64.so.2 (0x0034b060) libc.so.6 = /lib64/libc.so.6 (0x7f1d8c5d5000) [...] Anyway, to pull in steam.i386, the steam.i386 package would need to be in the repository as well, so the problem is the same. I think the best and cleanest way is to create an i686 package and installing it as it should. Getting to something like ELRepo nvidia packages with a nvidia-x11-drv-libs-32bit.x86_64 package containing i686 libraries is a really, really ugly thing and I would rather not do it... Leaving it as is and simply adding x86_64 to ExclusiveArch would allow us to rebuild the package as normal. Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/
Re: CDRtools in RPMFusion
On Wed, Oct 23, 2013 at 12:10 PM, Simone Caronni negativ...@gmail.comwrote: Hello, I would like to merge my current CDRtools package [1] in RPMFusion. It currently has quite a large user base. It is used by people who needs to burn Dual Layer DVDs or Blue Ray discs. Currently cdrkit (wodim) is not able to burn them; actually it never had since its first exception. Sounds good. I looked at it earlier but eventually gave up not only because of the license issue (I was taking another shot at getting it in Fedora) but because it doesn't replace the existing tools 1:1 so packaging just got too complicated for my level of interest. Additionally I got my BD-R discs burning quite well using cdrskin via libburn. I can help with the package reviews if the other issues you mention get worked out. Thanks, Richard
Re: i686 binary packages in the x86_64 repository
2013/10/23 Simone Caronni negativ...@gmail.com Hello, the Steam review has been taken, however the reviewer wonders if the infrastructure can cope with i686 binary packages being pushed to the x86_64 repository. I thought it was possible, but this is my first Hi Simone From the plague infrastructure perspective there is no issue with having the i686 package automatically copied into the x86_64 repository. From the package you will only need to use ExclusiveArch: i686 That way the package will be built only for the i686 target. Then I will adjust the package to be copied into the x86_64 repository on plague configuration. This might be different with koji (where some special cases might be handled within mash instead). Thx for this review. Nicolas (kwizart)
[Bug 2979] Review request: steam - Installer for the Steam software distribution service
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2979
--- Comment #35 from Alec Leamas leamas.a...@gmail.com 2013-10-23 21:34:33
CEST ---
Package Review
==
Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
= MUST items =
Issues:
- Nicholas suggests using ExclusiveArch: i686, lets stick to that.
Generic:
[!]: Package is licensed with an open-source compatible license and meets
other legal requirements as defined in the legal section of Packaging
Guidelines.
-- OK for rpmfusion.
[x]: License field in the package spec file matches the actual license.
Note: Checking patched sources after %prep for licenses. Licenses found:
Unknown or generated. 1 files have unknown license. Detailed output of
licensecheck in /home/mk/FedoraReview/2979-steam/licensecheck.txt
[x]: Package must own all directories that it creates.
Note: Directories without known owners: /usr/lib/udev, /etc/profile.d,
/usr/lib/udev/rules.d
[-]: %build honors applicable compiler flags or justifies otherwise.
[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]: update-desktop-database is invoked in %post and %postun if package
contains desktop file(s) with a MimeType: entry.
Note: desktop file(s) with MimeType entry in steam
[x]: gtk-update-icon-cache is invoked in %postun and %posttrans if package
contains icons.
Note: icons in steam
[x]: Useful -debuginfo package or justification otherwise.
[-]: Package is not known to require an ExcludeArch tag.
Well, it does, it's correct and that's how it is.
[-]: Large documentation must go in a -doc subpackage. Large could be size
(~1MB) or number of files.
Note: Documentation size is 30720 bytes in 4 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]: 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]: 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.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps
[Bug 2979] Review request: steam - Installer for the Steam software distribution service
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2979 Alec Leamas leamas.a...@gmail.com changed: What|Removed |Added Blocks|3 |4 Depends on|4 | -- 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 2979] Review request: steam - Installer for the Steam software distribution service
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2979 Alec Leamas leamas.a...@gmail.com changed: What|Removed |Added Depends on||4 --- Comment #36 from Alec Leamas leamas.a...@gmail.com 2013-10-23 21:36:03 CEST --- Package looks good (fix the ExclusiveArch, though) *** APPROVED -- 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 2979] Review request: steam - Installer for the Steam software distribution service
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2979
--- Comment #37 from Simone Caronni negativ...@gmail.com 2013-10-23 21:38:55
CEST ---
Latest comments, just for reference...
On 23 October 2013 20:06, Alec Leamas wrote:
Besides that, this discussion draws my attention to all these %{_isa} suffixes
in the explicit deps. It doesn't really makes sense IMHO. %_isa is the way to
dynamically refer to the architecture. However, these are all 32-bit deps,
which means that %_isa can't be anything but (x86-32). Now, if we always build
on a 32-bit host the net result is the same. But needlessly complicated, and I
wonder if not an explicit '(x86-32)' is a better option in this case?
Creating a 64 bit package, with all libraries and programs written in as
library(x86-32) in the requirements is really ugly.
After installing the Steam client, there are hints (libraries, a stub Ubuntu
runtime, etc.) that the client will sooner or later ported to 64 bit; so
creating a package like that would create a lot of mess. Example:
$ ls -ald ubuntu12_*
drwx--. 2 slaanesh slaanesh 4096 Oct 20 19:57 ubuntu12_32
drwxrwxr-x. 2 slaanesh slaanesh 4096 Oct 10 23:37 ubuntu12_64
$ ls -al ubuntu12_64/
total 15460
drwxrwxr-x. 2 slaanesh slaanesh 4096 Oct 10 23:37 .
drwx--. 26 slaanesh slaanesh 4096 Oct 23 16:37 ..
-rwxrwxr-x. 1 slaanesh slaanesh 472576 Oct 4 02:47 crashhandler.so
-rwxrwxr-x. 1 slaanesh slaanesh 173323 Sep 27 19:57 gameoverlayrenderer.so
-rwxrwxr-x. 1 slaanesh slaanesh 191997 Sep 25 23:57 libtier0_s.so
-rwxrwxr-x. 1 slaanesh slaanesh 235937 Oct 4 02:47 libvstdlib_s.so
-rwxrwxr-x. 1 slaanesh slaanesh 14739300 Oct 9 04:25 steamclient.so
$ ldd ubuntu12_64/steamclient.so
linux-vdso.so.1 = (0x7fff6673c000)
[...]
libstdc++.so.6 = /lib64/libstdc++.so.6 (0x7f1d8cbb3000)
libpthread.so.0 = /lib64/libpthread.so.0 (0x7f1d8c997000)
/lib64/ld-linux-x86-64.so.2 (0x0034b060)
libc.so.6 = /lib64/libc.so.6 (0x7f1d8c5d5000)
[...]
So a guess is that a 64 bit Steam client will be probably released (maybe on
the new Steam machines already?) and leaving %_isa should allow you to rebuild
the package easily for x86_64 simply by adding it to the ExclusiveArch tag.
--
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 2979] Review request: steam - Installer for the Steam software distribution service
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2979
--- Comment #38 from Simone Caronni negativ...@gmail.com 2013-10-23 21:46:39
CEST ---
Thanks for the review!
One question about ExclusiveArch; %{ix86} already contains i686 and if (ever)
Fedora would switch to i786 or anything like that it would be included as well.
$ rpm --eval %{ix86}
i386 i486 i586 i686 pentium3 pentium4 athlon geode
I think Nicolas in the mail was referring more generically to the architecture
rather than the specific variant.
Asking on the mailing list.
--
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: i686 binary packages in the x86_64 repository
On 23 October 2013 20:49, Nicolas Chauvet kwiz...@gmail.com wrote:
From the plague infrastructure perspective there is no issue with having
the i686 package automatically copied into the x86_64 repository. From the
package you will only need to use ExclusiveArch: i686
Quick question. I have used ExclusiveArch: %{ix86} in the package, is that
ok?
$ rpm --eval %{ix86}
i386 i486 i586 i686 pentium3 pentium4 athlon geode
Is that ok for plague?
Thanks,
--Simone
--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
http://xkcd.com/229/
http://negativo17.org/
Re: i686 binary packages in the x86_64 repository
2013/10/23 Simone Caronni negativ...@gmail.com
On 23 October 2013 20:49, Nicolas Chauvet kwiz...@gmail.com wrote:
From the plague infrastructure perspective there is no issue with having
the i686 package automatically copied into the x86_64 repository. From the
package you will only need to use ExclusiveArch: i686
Quick question. I have used ExclusiveArch: %{ix86} in the package, is that
ok?
$ rpm --eval %{ix86}
i386 i486 i586 i686 pentium3 pentium4 athlon geode
Is that ok for plague?
No. This, in plague, will build each variant where we only wanted one of
them. (currently i686).
Nicolas (kwizart)
Re: CDRtools in RPMFusion
On Wed, 23 Oct 2013 13:39:57 -0500 Richard Shaw hobbes1...@gmail.com wrote: On Wed, Oct 23, 2013 at 12:10 PM, Simone Caronni negativ...@gmail.comwrote: Hello, I would like to merge my current CDRtools package [1] in RPMFusion. It currently has quite a large user base. It is used by people who needs to burn Dual Layer DVDs or Blue Ray discs. Currently cdrkit (wodim) is not able to burn them; actually it never had since its first exception. Sounds good. I looked at it earlier but eventually gave up not only because of the license issue (I was taking another shot at getting it in Fedora) but because it doesn't replace the existing tools 1:1 so packaging just got too complicated for my level of interest. Additionally I got my BD-R discs burning quite well using cdrskin via libburn. IANAL, but I believe the same reasons that prevent inclusion of CDRtools into Fedora prevent it from inclusion into RPMFusion. The program is breaking free software licenses (CDDL linking GPL and the two are incompatible by design of CDDL), which makes redistribution (in binary form) impossible. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org
Re: CDRtools in RPMFusion
On 23 October 2013 22:17, Richard Shaw hobbes1...@gmail.com wrote: On Wed, Oct 23, 2013 at 2:52 PM, Susi Lehtola jussileht...@fedoraproject.org wrote: IANAL, but I believe the same reasons that prevent inclusion of CDRtools into Fedora prevent it from inclusion into RPMFusion. The program is breaking free software licenses (CDDL linking GPL and the two are incompatible by design of CDDL), which makes redistribution (in binary form) impossible. To be fair, Jorg believes that CDDL linking to GPL is not a problem, but Fedora legal felt otherwise. I think it would be fair to say that the license compatibility is unclear. I also looked at using an alternative C library (Clang) but I'm not enough of a programmer to do that. I think the most relevant part for banning cdrtools was the behaviour of the main developer :) So do you think this unclear compatibility means a no-go for RPMFusion inclusion? Or on the contrary could be included due to relaxed licensing compared to Fedora? FreeBSD ships some patches for compiling CDRtools with Clang, if I can assemble the package with it would be ok? --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/
Re: CDRtools in RPMFusion
On Wed, Oct 23, 2013 at 3:53 PM, Simone Caronni negativ...@gmail.comwrote: On 23 October 2013 22:17, Richard Shaw hobbes1...@gmail.com wrote: On Wed, Oct 23, 2013 at 2:52 PM, Susi Lehtola jussileht...@fedoraproject.org wrote: IANAL, but I believe the same reasons that prevent inclusion of CDRtools into Fedora prevent it from inclusion into RPMFusion. The program is breaking free software licenses (CDDL linking GPL and the two are incompatible by design of CDDL), which makes redistribution (in binary form) impossible. To be fair, Jorg believes that CDDL linking to GPL is not a problem, but Fedora legal felt otherwise. I think it would be fair to say that the license compatibility is unclear. I also looked at using an alternative C library (Clang) but I'm not enough of a programmer to do that. I think the most relevant part for banning cdrtools was the behaviour of the main developer :) Agreed. Jorg is very intelligent, but his people skills leave much to be desired. :) And it doesn't help that he refuses to change the license, or that he doesn't like make and had to come up with his own replacement, smake. So do you think this unclear compatibility means a no-go for RPMFusion inclusion? Or on the contrary could be included due to relaxed licensing compared to Fedora? FreeBSD ships some patches for compiling CDRtools with Clang, if I can assemble the package with it would be ok? I would say, possibly. You'd need to make sure it doesn't link to anything GPL... $ ldd cdrecord linux-vdso.so.1 = (0x7fffbe9fe000) libc.so.6 = /lib64/libc.so.6 (0x003f1c40) /lib64/ld-linux-x86-64.so.2 (0x003f1c00) But if you can do that, then it could technically go back in Fedora. Richard
Re: CDRtools in RPMFusion
Once upon a time, Richard Shaw hobbes1...@gmail.com said: I would say, possibly. You'd need to make sure it doesn't link to anything GPL... I don't think the compiler used is the problem (the output of gcc is not affected by gcc's license). IIRC the cdrecord problem is that some of the code is GPL and some is CDDL, so just building the code creates a mix of two incompatible licenses. -- Chris Adams li...@cmadams.net
RPM Fusion (Fedora - free) Package Build Report 2013-10-24
Packages built and released for RPM Fusion (Fedora - free) development: 7 NEW gxine-0.5.907-11.fc20 : GTK frontend for the xine multimedia library k9copy-2.3.8-6.fc20 NEW kaffeine-1.2.2-7.fc20 : KDE media player NEW oxine-0.7.1-20.fc20 : Lightweight, purely OSD based xine frontend NEW xine-lib-1.2.4-2.fc20 : A multimedia engine NEW xine-plugin-1.0.2-9.fc20 : Mozilla/Netscape compatible media plugin NEW xine-ui-0.99.7-9.fc20 : A skinned xlib-based gui for xine-lib Changes in RPM Fusion (Fedora - free) development: gxine-0.5.907-11.fc20 - * Wed Oct 23 2013 Xavier Bachelot xav...@bachelot.org - 0.5.907-11 - Rebuild for xine-lib 1.2. k9copy-2.3.8-6.fc20 --- * Wed Oct 23 2013 Xavier Bachelot xav...@bachelot.org - 2.3.8-6 - Rebuild for xine-lib 1.2. kaffeine-1.2.2-7.fc20 - * Wed Oct 23 2013 Xavier Bachelot xav...@bachelot.org - 1.2.2-7 - Rebuild for xine-lib 1.2. oxine-0.7.1-20.fc20 --- * Wed Oct 23 2013 Xavier Bachelot xav...@bachelot.org - 0.7.1-20 - Rebuild for xine-lib 1.2. xine-lib-1.2.4-2.fc20 - * Sat Oct 12 2013 Xavier Bachelot xav...@bachelot.org 1.2.4-2 - Make the build more verbose. - Don't run autogen.sh gratuitously and drop BR: autoconf automake libtool. Consequently, add a code snippet to remove rpath. - Drop obsolete no autopoint patch and Requires: gettext-devel instead. - Drop obsolete Requires: pkgconfig for -devel subpackage. - Drop obsolete Group: tags. - Bump xine-lib-extras-freeworld Obsoletes:. * Tue Sep 24 2013 Xavier Bachelot xav...@bachelot.org 1.2.4-1 - Update to 1.2.4. - Drop upstream'ed patches and hacks. - More spec file cleanup. xine-plugin-1.0.2-9.fc20 * Wed Oct 23 2013 Xavier Bachelot xav...@bachelot.org - 1.0.2-9 - Rebuild for xine-lib 1.2. xine-ui-0.99.7-9.fc20 - * Wed Oct 23 2013 Xavier Bachelot xav...@bachelot.org - 0.99.7-9 - Rebuild for xine-lib 1.2.
