openmw: fc27 rebuild needed [RFBZ#4662]

[Ralf Corsepius]

Hi,

Would somebody with the appropriate privileges please look into
https://bugzilla.rpmfusion.org/show_bug.cgi?id=4662 ?

This package currently is not installable for fc27 due to an SONAME bump 
in a library this package depends on. It would need a rebuild for fc27.


Ralf
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

Re: RPMFusion or Fedora?

[Ralf Corsepius]

On 12/18/2016 01:05 AM, Alec Leamas wrote:

I think Ralf refers to the rules for games and emulators simply because this is 
a game application.


Not quite. I am primarily looking at this from the angle of "distro 
integrity" and "system security".


That said, I consider any package
- "calling home" to be violating "data privacy"
- "downloading something" to a security risk.
- installing something outside of rpm's control to be non-maintainable.


However, IMHO the answer here really  depends the type of the database 
downloaded from the server.


I don't know anything about this game, but my gut feeling is the risk 
such a game implies should be considered inacceptable.


Can you exclude these game files can be abused for viruses, troyans and 
other backdoor? Can you exclude these servers doesn't spy at you or 
collect personalized data? I don't think anybody can.


Anyway, in Fedora, we in general mandate "call homes" to be removed and 
mandate packages to be "self-contained".



Ralf

___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

Re: RPMFusion or Fedora?

[Ralf Corsepius]

On 12/17/2016 07:17 AM, Link Dupont wrote:

I'm trying to decide whether a package should go into RPMFusion or
Fedora.

It's a project called Cockatrice[1]. Cockatrice is an open-source
"virtual tabletop for multiplayer card games". While it does not bundle
any copyrighted content (such as images or even databases of cards),
the software is effectively useless without a database of cards. It
does not enforce the *rules* of these multi-player card games; it
merely provides a framework of controls in order to play these games
"virtually". It does ship a utility that easily will download (from a
third party) a card database, and has code that will download images at
run time.

I feel like this could technically below in Fedora, but I'm not sure.
Thoughts?


A package, which downloads/side-loads stuff from sources out of Fedora 
and operates outside of rpm's control is not acceptable in Fedora (and 
should not be acceptable in RPMFusion, as well).



What you could do,
- is to modify the "framework package" in such a way it doesn't download 
any package.
- and to package the the license encumbered "data files" into rpmfusion 
to bring them under rpm's control. However this is only applicable if 
these files' licenses permit "repackaging"/"redistribution", otherwise 
you are out of luck. In this case, you may ask upstream to change their 
licensing or may opt implement a free "card database".


Ralf
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

Re: build perl problem

[Ralf Corsepius]

On 10/25/2016 09:46 AM, Emmanuel Seyman wrote:

* Nicolas Chauvet [24/10/2016 14:49] :


2016-10-21 22:03 GMT+02:00 Nicolas Chauvet :


Other topic, but related to perl. Can anyone can explain why
perl-generator isn't part of perl-devel if not the case already ?


Anyone to answear the question ?


This was done so that packages that contain a perl script do not have to have
perl-devel as a BuildRequires (because this is considered expensive)


Exactly, but there is more to it:

perl-devel is an ordinary *-devel package, just like any other *-devel 
package. It contains headers, link-libraries etc.


perl-generators actually is more or less more a subpackage of rpm-build, 
which adds some scripts and macros to rpmbuild (IIRC, it was split out 
from rpm/rpm-build)


In other words, they serve different tasks and are not actually 
interconnected.


Ralf

Re: libdvdcss in RPM Fusion ?

[Ralf Corsepius]

On 09/06/2016 10:03 AM, Nicolas Chauvet wrote:

2016-09-06 9:48 GMT+02:00 Ralf Corsepius <rc040...@freenet.de>:

On 09/01/2016 06:56 PM, Xavier Bachelot wrote:


Nicolas, can you share your thoughts on this?


libdvdcss's legal situation in Germany is widely unclear[1].

According to German laws cracking "wirksame technische Maßnahmen“
("effective technical measures") of copy protection is unlawful.

The fundamental question in this context is: "Does CSS (still) qualify as an
effective technical measures of copy protection?"

Answer: Nobody knows. Only courts would be able to answer this question.

I.e. the legal risks of libdvdcss have not changed for years, i.e. should
libdvdcss binaries enter RPMFusion, esp. German RPMFusion mirror
owners/mirror managers are not unlikely to be confronted with legal action.


How many legal action have occurred ?


AFAICT, none. I am inclined to believe all German sites shied away from 
shipping libdvdcss, to avoid these risks.


Ralf

Re: libdvdcss in RPM Fusion ?

[Ralf Corsepius]

On 09/01/2016 06:56 PM, Xavier Bachelot wrote:


Nicolas, can you share your thoughts on this?

libdvdcss's legal situation in Germany is widely unclear[1].

According to German laws cracking "wirksame technische Maßnahmen“ 
("effective technical measures") of copy protection is unlawful.


The fundamental question in this context is: "Does CSS (still) qualify 
as an effective technical measures of copy protection?"


Answer: Nobody knows. Only courts would be able to answer this question.

I.e. the legal risks of libdvdcss have not changed for years, i.e. 
should libdvdcss binaries enter RPMFusion, esp. German RPMFusion mirror 
owners/mirror managers are not unlikely to be confronted with legal action.


Ralf

[1] https://de.wikipedia.org/wiki/Libdvdcss

Re: Reverse weak dependencies in RPMFusion packages

[Ralf Corsepius]

On 09/04/2016 12:40 AM, Kevin Kofler wrote:

Ralf Corsepius wrote:


On 09/03/2016 01:50 PM, Dominik 'Rathann' Mierzejewski wrote:

Dear RPMFusion contributors!

In light of https://fedorahosted.org/council/ticket/61 and
https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal
should we start adding Supplements: or Enhances: weak dependencies
to, say, ffmpeg and other packages?


IMHO, no. This decision is severe mistake.


Why? This use case is exactly what the reverse versions are for. The Fedora
repository should not know about RPM Fusion,

Fedora must not know about any 3rd party repo.


RPM Fusion should know about
Fedora.  So why should Fedora carry the weak dependencies on RPM Fusion
packages?

Fedora must not carry any deps of any kind to any 3rd party repo.

... RPM Fusion doesn't have any reason to use weak deps instead of hard 
deps[1], but featuritis.


Ralf

[1] That said, I do not see any reason for Fedora to carry weak deps at 
all, at least for now, because Fedora's tooling (Noteworthy: dnf) still 
doesn't seem to be able handle them properly.

Re: Reverse weak dependencies in RPMFusion packages

[Ralf Corsepius]

On 09/03/2016 01:50 PM, Dominik 'Rathann' Mierzejewski wrote:

Dear RPMFusion contributors!

In light of https://fedorahosted.org/council/ticket/61 and
https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal
should we start adding Supplements: or Enhances: weak dependencies
to, say, ffmpeg and other packages?


IMHO, no. This decision is severe mistake.

Ralf

Re: ffmpeg for EL7

[Ralf Corsepius]

On 08/25/2016 02:28 PM, Dominik 'Rathann' Mierzejewski wrote:

On Thursday, 25 August 2016 at 10:24, Ralf Corsepius wrote:

On 08/25/2016 10:01 AM, Nicolas Chauvet wrote:

[...]

Specially as ffmpeg doesn't do symbol version, if one process has
dependencies using both version, it will crash.

AFAIU, as long as these packages are properly linked (and not libraries
not being dlopened), package deps on SONAMEs would conflict and thus
prevent such problems.


The point is that not all SONAMEs change with each FFmpeg version bump,
so, for example, ffmpeg-3.0.x and ffmpeg-3.1.x may have mostly the same
SONAMEs.


This would mean these are ABI compatible.

I haven't tried to check and verify actual situation wrt. ffmpeg.


Ralf

Re: ffmpeg for EL7

[Ralf Corsepius]

On 08/25/2016 10:01 AM, Nicolas Chauvet wrote:


I don't quite understand the proposition related to ffmpeg. Using
version in name doesn't seem to say which one should be chosen by
default for link.
As you probably know, ffmpeg supports versioned executables, installdirs 
etc.


Building an ffmeg2* package which is installable in parallel to ffmpeg 
actually is pretty straight forward. Building a parallel installable 
ffmpeg2-devel, would be more difficult, though. However, provided 
packages are being built in chroots/mock/koji, these days, I do not see 
a pressing need for a parallel installable ffmpeg2-devel.



Specially as ffmpeg doesn't do symbol version, if one process has
dependencies using both version, it will crash.
AFAIU, as long as these packages are properly linked (and not libraries 
not being dlopened), package deps on SONAMEs would conflict and thus 
prevent such problems.


Ralf

Re: ffmpeg for EL7

[Ralf Corsepius]

On 08/25/2016 09:10 AM, Nicolas Chauvet wrote:

2016-08-25 7:13 GMT+02:00 Ralf Corsepius <rc040...@freenet.de>:

On 08/24/2016 08:19 PM, Orion Poplawski wrote:



One suggestion that's been getting more traction on the EPEL side of
things is
to just start with versioned packages that can co-exist.  So start with
ffmpeg2.8 and ffmpeg3.0 from the start.



I would suggest to extend this approach to Fedora-24, to make packaging a
vlc-2.x possible, because vlc-3.0 in fc24 is "just plain unusable" for me
and vlc-2.x doesn't seem to support ffmpeg-3.0.

Care to explain what's the issue ? works for me here.


Where shall I start? I am having such an amount of, partially serious 
partially less serious problems with it, I am having difficulties in not 
ranting ;)


So, let me just mention 3 most nagging ones:

1. vlc-3 very frequently (almost each time) eats up all memory (incl. 
swap) until the machine runs OOM and starts killing other programs rsp. 
other programs crash and even lockup machine entirely.


2. vlc-3 doesn't scale many videos correctly, which fc23's vlc-2.x had 
displayed correctly.


3. vlc-3 opens a dialog popup for streams it can't handle. vlc-2.x 
simply ignored them.



#1 is the real killer. It happens such kind of frequently I would 
estimate vlc-3.0's MTBF to ~2 minutes.


That said, I have no real idea about the causes, but am pretty sure 
there several causes interacting.


- From having monitored upstream activities, I know upstream vlc is 
struggling with concurrency and deadlock issues.
- From other display/graphics related issues I am having[1], I am also 
pretty sure some low level intel-GPU related stuff is bugged (kernel, 
libvdpau-intel, xorg-x11-*, ...)
- I am observing vlc issuing qt-warnings complaining about "Timers can 
not be stopped from another thread"



(Gnome3, NVIDIA)


xfce4, Intel IGP (i5-4570)

I haven't seen these issues with xfce4/NVidia, yet.

Ralf

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

Re: ffmpeg for EL7

[Ralf Corsepius]

On 08/24/2016 08:19 PM, Orion Poplawski wrote:


One suggestion that's been getting more traction on the EPEL side of things is
to just start with versioned packages that can co-exist.  So start with
ffmpeg2.8 and ffmpeg3.0 from the start.


I would suggest to extend this approach to Fedora-24, to make packaging 
a vlc-2.x possible, because vlc-3.0 in fc24 is "just plain unusable" for 
me and vlc-2.x doesn't seem to support ffmpeg-3.0.



SCLs are a major pain.


Definitely.

Ralf

Re: SIMD vs no SIMD on i686

[Ralf Corsepius]

On 07/19/2016 02:26 PM, Nicolas Chauvet wrote:


As I state before, I think, even in this case, x264 asm code, have a
fall back when don't have sse2 instructions and don't crash, that is my
point, but just testing to be sure. I don't see any hardware here to
test it, even though it is a big challenge try install Fedora 24 in
a non-sse2 capable cpu .

Well, it's not easy to install F24, but it's doable.


You could setup a x86 32bit virtual machine using KVM install fedora,
then mask cpu, or use pentium 3 as a CPU for the guest vm and reboot.

I do have a PIII (w/o sse3) running F24.

Ralf

Re: [terminatorX/f24] Change from gtk2 to gtk3

[Ralf Corsepius]

On 07/20/2016 01:47 AM, Sérgio Basto wrote:

On Qua, 2016-07-20 at 00:37 +0100, Sérgio Basto wrote:

On Qua, 2016-07-20 at 00:28 +0200, Dominik 'Rathann' Mierzejewski
wrote:


On Wednesday, 20 July 2016 at 00:00, Leigh Scott wrote:



Summary of changes:

  3dc7333... Change from gtk2 to gtk3 (*)

(*) This commit already existed in another branch; no separate
mail
sent

Could you explain why you're changing user experience in stable
branches?



f24 is a stable branch ?!?


Definitely, yes. RPMFusion is supposed to adopt Fedora's policies.


For f23 I understand the question , for f24 I think RPMFusion isn't yet
closed , since many packages aren't publish yet like this terminatorX


Well, barring the fact RPMFusion for 24 is in pretty miserable shape, I 
don't see how your argument should be relevant here.



Ralf

Re: [xcpc] Built against libXaw because lesstif has been retired for F24

[Ralf Corsepius]

On 07/19/2016 12:48 PM, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 19 July 2016 at 12:16, Ralf Corsepius wrote:

On 07/19/2016 09:26 AM, Andrea Musuruane wrote:

On Tue, Jul 19, 2016 at 1:04 AM, Dominik 'Rathann' Mierzejewski
<domi...@greysector.net <mailto:domi...@greysector.net>> wrote:

On Sunday, 17 July 2016 at 17:01, Andrea Musuruane wrote:
> commit a0cdaee43b67a890b569ca6043f73183f9474134
> Author: Andrea Musuruane <musur...@gmail.com
<mailto:musur...@gmail.com>>
> Date:   Sun Jul 17 17:01:36 2016 +0200
>
> Built against libXaw because lesstif has been retired for F24

You could've switched to openmotif instead, but of course it's your
call.


No, I couldn't. Opermotif only supports motif2 API while xcpc requires
motif1 API :(


You seem to be confused.

F24 ships with Motif (not OpenMotif - OpenMotif is obsolete).


openmotif package is obsolete (still available in EL-5/6), but it was
re-added to Fedora as motif, so we are actually talking about the same
thing after all.

Not quite. OpenMotif used to be the "free" branch of Motif.

The "Motif" package is the "real thing", which was closed source for 
decades.


Ralf

Re: [xcpc] Built against libXaw because lesstif has been retired for F24

[Ralf Corsepius]

On 07/19/2016 09:26 AM, Andrea Musuruane wrote:

On Tue, Jul 19, 2016 at 1:04 AM, Dominik 'Rathann' Mierzejewski
> wrote:

On Sunday, 17 July 2016 at 17:01, Andrea Musuruane wrote:
> commit a0cdaee43b67a890b569ca6043f73183f9474134
> Author: Andrea Musuruane >
> Date:   Sun Jul 17 17:01:36 2016 +0200
>
> Built against libXaw because lesstif has been retired for F24

You could've switched to openmotif instead, but of course it's your
call.


No, I couldn't. Opermotif only supports motif2 API while xcpc requires
motif1 API :(


You seem to be confused.

F24 ships with Motif (not OpenMotif - OpenMotif is obsolete).

That said, building xcpc against Motif appears to work perfectly.

Ralf

Re: libraries missing on F22 and higher

[Ralf Corsepius]

On 12/29/2015 11:28 AM, Sérgio Basto wrote:


For example Mosaic-2.7-0.3.b5.fc11.x86_64 still works on Fedora 23
, but is a FTBFS since F12 or 13 . So fail to build is not
equivalent to fail to run .



Works but surely does not respect anymore all Packaging guidelines of
Fedora.


What guideline that is not respected ?


- Fedora packages must be buildable (An FTBFS alone is a violation of 
the FPG)
- fc12/13 were using different CFLAGS, paths and rpm. It's very likely 
these packages are vulnerable and unusable.

- Fedora packages must carry the current release %dist.

That said, packages which FTBFS since F12 should be removed and abandoned.

Ralf

Re: libraries missing on F22 and higher

[Ralf Corsepius]

On 12/27/2015 01:11 AM, Sérgio Basto wrote:


Also, RPMFusion respects Fedora packaging guidelines or not?


yes we do


Aparently RPMFusion does not repect the FPG. Packages complying to the 
FPG are supposed to have been rebuilt for f23 and therefore to carry a 
package suffix of ".f23".


The fact Fedora carries packages with a package suffix != .fc23 isn't a 
valid excuse. Technically this simply means these packages FTBS'ed.


Ralf

Re: NVidia update status?

[Ralf Corsepius]

On 11/18/2015 05:51 PM, Sérgio Basto wrote:

On Qua, 2015-11-18 at 13:38 +0100, Ralf Corsepius wrote:

Hi,

NVidia released new xorg-1.18 compatible drivers earlier this week.

So, ... what is holding up rpmfusion from shipping them for f23?


is out
dnf repoquery \*nvidia\* --qf "%{name} %{version}-%{release} %{repoid} 
%{sourcerpm}" | grep rpmfusion
akmod-nvidia-340xx 340.96-1.fc23 rpmfusion-nonfree-updates-testing 
nvidia-340xx-kmod-340.96-1.fc23.src.rpm
kmod-nvidia-340xx 340.96-1.fc23 rpmfusion-nonfree-updates-testing 
nvidia-340xx-kmod-340.96-1.fc23.src.rpm
kmod-nvidia-340xx-4.2.3-300.fc23.x86_64 340.96-1.fc23 
rpmfusion-nonfree-updates-testing nvidia-340xx-kmod-340.96-1.fc23.src.rpm
xorg-x11-drv-nvidia-340xx 340.96-1.fc23 rpmfusion-nonfree-updates-testing 
xorg-x11-drv-nvidia-340xx-340.96-1.fc23.src.rpm
xorg-x11-drv-nvidia-340xx-cuda 340.96-1.fc23 rpmfusion-nonfree-updates-testing 
xorg-x11-drv-nvidia-340xx-340.96-1.fc23.src.rpm
xorg-x11-drv-nvidia-340xx-devel 340.96-1.fc23 rpmfusion-nonfree-updates-testing 
xorg-x11-drv-nvidia-340xx-340.96-1.fc23.src.rpm
xorg-x11-drv-nvidia-340xx-kmodsrc 340.96-1.fc23 
rpmfusion-nonfree-updates-testing 
xorg-x11-drv-nvidia-340xx-340.96-1.fc23.src.rpm
xorg-x11-drv-nvidia-340xx-libs 340.96-1.fc23 rpmfusion-nonfree-updates-testing 
xorg-x11-drv-nvidia-340xx-340.96-1.fc23.src.rpm


Thanks, nvidia-340.96 seems to work for me.

Ralf

NVidia update status?

[Ralf Corsepius]

Hi,

NVidia released new xorg-1.18 compatible drivers earlier this week.

So, ... what is holding up rpmfusion from shipping them for f23?

Ralf

Re: ffmpeg-2.4 released

[Ralf Corsepius]

On 09/21/2014 11:20 PM, Sérgio Basto wrote:

On Dom, 2014-09-21 at 19:03 +0200, Julian Sikorski wrote:

Dear all,

ffmpeg-2.4 was released recently which means we have another rebuild
coming up. I have done a test and only 4 packages have failed, which is
not bad given the extent of API changes:
- alsa-plugins-freeworld: pcm_a52.c:101:45: error: 'struct a52_ctx' has
no member named 'frame'
- dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was not declared
in this scope
- kmediafactory: videofile.cpp:74:45: error: 'av_find_stream_info' was
not declared in this scope (mencoder needs to be rebuilt first)
  - vlc: configure: error: libavcodec versions 56 and later are not
supported yet.

Given that we are close to branching (?), what would be the good time to
do the rebuild?


yes, I don't see any problem, I can do the mass rebuild of others
packages, no problem.

My question if we ever put this updates on F20 ?


No. If I understand correctly, this is an API/ABI incompatible upgrade 
and not an ordinary update. This means, unless there are very good 
reasons (e.g. security critical bug fixes), which make such upgrades 
inevitably necessary, such upgrades are harmful and should not happen.
Keep in mind, people might build other packages based on your packages, 
which might break because of your upgrade.



I'd like put it at
least on update-testing.

Sorry, but this can't work.

Ralf

Re: FFmpeg bundling exception for XBMC

[Ralf Corsepius]

On 02/24/2014 07:20 AM, Ken Dreyer wrote:

Hi folks,

Alex Lancaster recently pointed out that XBMC upstream has completely
removed the option to use an external FFmpeg.

https://github.com/xbmc/xbmc/pull/4005

FFmpeg has been a long ongoing saga with XBMC. The XBMC developers
develop their own patches to their private FFmpeg fork, and Alex and I
have had various success or failure over the years with unbundling
FFmpeg in the past. Unfortunately XBMC has recently taken steps in the
direction to make this harder, at least for the v13 Gotham release.

The summary is that Alex and I need a bundling exception from the RPM
Fusion developer community in order to keep XBMC in RPM Fusion.

--

 From what I can tell, the three reasons that the XBMC developers
bundle FFmpeg are:


There are 2 strong reasons to not bundle FFMPEG:
* Users (eg. me) rebuild rpmfusion's ffmpeg with options not supported 
by rpmfusion:
= rpmfusion bundling xbmc's ffmpeg would void this undertaking and 
reduce rpmfusion's usability.


* ffmpeg is quite security sensitive (AFAICT, e.g. Google recently 
reported (IIRC), ca. 1000 bugs, which reportedly were incorporated into 
upstream ffmpeg)

= XBMC's bundling imposes severe security risks on both XMBC and rpmfusion

That said, I am quite opposed to let rpmfusion bundle ffmpeg and am in 
favor of staying hard for didacitcal, to teach upstream XBMC that their 
undertaking is counterproductive.



Ralf

Re: Packaging 3-rd party repositories in rpmfusion

[Ralf Corsepius]

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

Re: Packaging 3-rd party repositories in rpmfusion

[Ralf Corsepius]

[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).

My basic understanding is that current Fedora guidelines needs a
interpretation in the rpmfusion context. Those brand new GL for 3-rd
party repos are in [2] (discussions in [3]). For now, I think they can
be abridged to:
- Non-free repos can not be part of Fedora yum configuration.
- In some cases free repos can be part of the configuration after
FESCO/Fedora legal approval.

Now, IMHO this doesn't really make much sense for rpmfusion for three reasons:
- rpmfusion does not ban non-free software, it's one of the very
reasons it exists.
- FESCO/Fedora legal cannot approve anything in rpmfusion.
- We already have a list of endorsed 3-rd party repos [4].

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.


In other words, I'd recommend not doing so, because you guys are likely 
to be facing very tough times in cases something goes wrong with these 
endorsed 3rd party repos.


Ralf

Re: Request of bundling exception

[Ralf Corsepius]

On 09/28/2013 03:56 PM, Alec Leamas wrote:


It might be that the shiny package just is some source code and not 
actually linked against.

Would you mind to explain what you mean by this?

It doesn't parse to anything I understand.

Ralf

Re: open build service builds rpmfusion

[Ralf Corsepius]

On 08/23/2012 04:33 PM, Damian Ivanov wrote:

Hi,

@ Christopher
Sorry but I don't see which wiki you mean, can you link it?
Well it's a server, I am quite sure that Fedora will not fairly soon
dump koji/mock/bodhi but rpmfusion could start,
I don't see a reason to no get it into Fedora repos, maybe if Fedora
don't accept it, OBS should go into rpmfusion :)


The only legitimate reasons Fedora could reject OBS package submissions 
would be legal reasons or technical reasons.


In case of legal reasons, rpmfusion could adopt it.

In case of technical reasons, rpmfusion will hardly be able to take 
over, because the repo hosting a package doesn't change much about the 
technical issues a package might excluded from Fedora.



@ Ken
Yeah I will have look than to get OBS tools into main fedora repos,
but if they don't accept it because it's a tool
from SuSE it may should land into rpmfusion ;)


Fedora is supposed to accept packages independently of their origins, as 
long as they comply to the Fedora package inclusion criteria (Permissive 
licensing, sufficiently stable SW etc.).


Ralf

Re: Updating mplayer: how about using bundled ffmpeg?

[Ralf Corsepius]

On 02/27/2012 02:55 AM, Kevin Kofler wrote:

Julian Sikorski wrote:

I was trying to update mplayer and most of the problems I am having are
due to using shared ffmpeg, which is discouraged and unsupported by
upstream. The latest error is:

libmpdemux/mp_taglists.c:27:34: fatal error: libavformat/internal.h: No
such file or directory

when trying to build 20120204 snapshot. Looking at the svn log, this was
added in revision 34243 (from 20111023). This all seems to indicate that
trying to use system ffmpeg is an uphill battle which will always going
to keep our mplayer behind, as well as piss upstream off when we come
asking for help.


I don't think bundling is an acceptable solution, especially with something
like FFmpeg which has security updates quite frequently.


+1

Ralf

Re: Devel builds broken?

[Ralf Corsepius]

On 02/06/2012 03:18 PM, Nicolas Chauvet wrote:

2012/2/6 Richard Shawhobbes1...@gmail.com:

I've never gotten this error[1] before:

ransaction Summary

Upgrade  27 Package(s)

Total size: 30 M
RPM needs to be updated
ERROR You need to update rpm to handle:
rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3-2.fc17.x86_64
  You could try running: rpm -Va --nofiles --nodigest
Your transaction was saved, rerun it with: yum load-transaction
/tmp/yum_save_tx-2012-02-06-15-03DeCmYD.yumtx

Any ideas?

Can you try to reproduce with a local mock on your machine, if not
done already ?

I was hit by this in my local mocks earlier today.

rm -rf /var/cache/mock/fedora-rawhide-*
fixed it.


It's probably related to the recent UsrMove change and maybe need to
clean the mock cache on the builder if the repository itself is in
good shape.


That's my guess as well - This stuff is improperly implemented.


Ralf

Re: gcc 4.7 programming question related to MythTV

[Ralf Corsepius]

On 02/05/2012 02:20 PM, Richard Shaw wrote:

I was trying to build the latest 0.24/fixes branch of MythTV and ran
into an issue where many C files were using functions (usleep, write,
close, gethostname, etc.) that were not available/(in scope?). It
turns out that unistd.h provided these functions so I included it in
all the offending files which allowed building to complete.

Is there any reason this would be unsafe (or non-portable)?
No, nowadays, presuming unistd.h to be present is pretty safe, because 
it has been part of POSIX for ages and is likely present on all POSIX'sh 
environments.


c.f.:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html

Somewhat oversimplified, in practice, this means, #include unistd.h is 
safe except on Windows.


Whether a particular version of unistd.h will provide the missing 
decls, is a different story.
 Some (ancient) OSes still could be shipping ancient or broken versions 
of unistd.h which do not supply the decls current POSIX would expect 
unistd.h to supply. However, this would not be worse than the current 
situation - Compilers could continue to complain about missing 
symbols/decls.


Ralf

Re: akmods: You think I would have learned my lesson with avidemux :)

[Ralf Corsepius]

On 09/23/2011 06:12 PM, Richard Shaw wrote:

On Thu, Sep 22, 2011 at 11:00 PM, Kevin Koflerkevin.kof...@chello.at  wrote:

Richard Shaw wrote:

I'm guessing here, but I assume the reason for Before=prefdm.service
is to make sure akmods runs prior to X coming up?


Even though I didn't write that line, I'm fairly sure that's what it is for.
Starting up X before your graphics driver finished compiling is not going to
work properly.

That said, the problem there is, this works for graphics drivers, but what
about akmods for wireless networking, for example? If you have systemwide
wireless connections set up in NetworkManager, you have to have the akmod
built before NetworkManager starts up. But if you only use akmods for a
graphics driver, or even for some obscure driver not needed at bootup at
all, your boot will block needlessly if NetworkManager waits for them.

The problem is, ordering constraints are highly dependent on what akmods
you're actually using.



Sounds like for the time being we need to go with the safest
(earliest) point for the time being.

Right.


Does prefdm fit this requirement?

I'd say no, Prefdm is one of the latest services being started.

It may suffice the graphics driver case, it's very likely much too late 
for other modules, because services before prefdm will require activated 
kmods to be able to start up properly (printer drivers. network drivers 
(consider ldap/nis-based authentication, nfs-based-autofs etc.)


Openly said, I doubt there is any suitable point :-)

Ralf

Re: ZSNES FTBFS

[Ralf Corsepius]

On 09/04/2011 04:39 PM, Andrea Musuruane wrote:

Hi,
 I was going to update ZSNES to explicitly requires pulseaudio-libs
(BZ #1926) and I found out that ZSNES doesn't compile with gcc 4.6.0
(F15+).

The buildlog is here (for devel):
http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/10187-zsnes-1.51-8.fc16/i686/build.log

The problem seems to be that _FORTIFY_SOURCE breaks parsegen:
https://bugs.launchpad.net/ubuntu/+source/zsnes/+bug/819774/comments/8

Ubuntu *fixed* this disabling _FORTIFY_SOURCE for parsegen. This is
not permitted in Fedora. Unluckily I don't have the necessary
knowledge to fix this myself.

Any help is appreciated.


From what I can gather, parsegen is choking upon 
-Wp,-D_FORTIFY_SOURCE being passed as argument to it.


At least separating the call to the compiler from parsegen's code 
generation seems to fix the issue.


c.f. patch below.

This lets parsegen generate *.h+*.c's and causes the *.c's to be 
compiled by normal compilation rules, instead of trying to compile 
them on the fly through parsegen.


Ralf
diff -Naur zsnes_1_51/src/Makefile.in zsnes_1_51.hacked/src/Makefile.in
--- zsnes_1_51/src/Makefile.in  2007-01-24 21:54:12.0 +0100
+++ zsnes_1_51.hacked/src/Makefile.in   2011-09-05 04:35:09.297967796 +0200
@@ -94,8 +94,8 @@
@CC@ @CFLAGS@ -o $@ -c $
 %.o: %.cpp
@CXX@ @CXXFLAGS@ -o $@ -c $
-%.o %.h: %.psr $(PSR)
-   ./$(PSR) @PSRFLAGS@ -gcc @CC@ -compile -flags @CFLAGS@ -O1 -cheader 
$*.h -fname $* $*.o $
+%.c %.h: %.psr $(PSR)
+   ./$(PSR) @PSRFLAGS@ -cheader $*.h -fname $* $*.c $
 
 default: main
 all: main tools

Re: OpenAFS and Static Libraries

[Ralf Corsepius]

On 03/04/2011 04:57 PM, Jack Neely wrote:


Secondly, many more experienced AFS administrators prefer the old
Transarc style paths over the FHS paths that my packages use.  I would
like to create an openafs-transarc sub-package that includes the
symlinks that would enable these non-standard paths.  (Specifically,
/usr/afs and /usr/vice.)


No way, never.


The first issue with the static libs really needs to happen.  The second
issue is just pure annoyance but will make these packages more usable to
certain folks.  I'd like to do both.  Are there any comments or reason
why I should not?


Because this transarc style doesn't comply to the FHS.

Ralf

Re: OpenAFS and Static Libraries

[Ralf Corsepius]

On 03/04/2011 06:28 PM, Ken Dreyer wrote:

On Fri, Mar 4, 2011 at 9:08 AM, Ralf Corsepiusrc040...@freenet.de  wrote:


Because this transarc style doesn't comply to the FHS.


I think FHS is a good thing to have. Several packages have exceptions,


They don't have an exception, they are broken rsp. certain people @RH 
are ignoring the FHS.


Ralf

Re: [solved] make install options in dvbcut - cant get it to use the proper rpm paths

[Ralf Corsepius]

On 03/04/2011 12:30 AM, Paul Howarth wrote:

On Fri, 04 Mar 2011 08:27:22 +1100
David Timmsdti...@iinet.net.au  wrote:


On 04/03/11 00:17, Paul Howarth wrote:

I think the Makefile already supports DESTDIR; try using:

make install \
  DESTDIR=%{buildroot} \
  bindir=%{_bindir} \
  helpdir=%{_datadir}/%{name} \
  mandir=%{_mandir}

OK, thanks guys.

I hadn't noticed the DESTDIR capability. I was reading
the ./configure --help, which mentions:




Where does DESTDIR definition come from ?
Where is it normally documented ?


It's fairly standard these days and comes for free with autotools
Not quite.  It comes for free with automake-based packages, as part of 
automake generated Makefile.ins.


This package however only applies autoconf and manually written 
Makefile.ins - I.e. somebody must have explictly implemented DESTDIR 
into the Makefile.ins.


Ralf

Re: Fwd: Build Error (Job 9114): desmume-0_9_7-1_fc15 on fedora-development-rpmfusion_free

[Ralf Corsepius]

On 02/28/2011 04:45 PM, Andrea Musuruane wrote:

On Sun, Feb 27, 2011 at 10:23 PM, Ralf Corsepiusrc040...@freenet.de  wrote:

Gtk's API was changed in Fedora 15. These symbols were deprecated in Gtk for
some time and now have been removed from Fedora's Gtk.

Have a look into the src.rpm of gtkglext-1.2.0-14, (Currently stuck in
Fedora QA's silly delay queue)
[https://admin.fedoraproject.org/updates/gtkglext-1.2.0-14]
for details of how a similar breakdown was fixed.


Thank you both for your feedback. I'll wait for gtkglext-1.2.0-14 and
then I'll try a new build.


Ooops - I missed that it's gtkglext itself, which breaks your
built ;)

To my knowledge, Fedora's QA $deities meanwhile have decided to push 
gtkglext into Fedora's local built-root.


May-be some time, somebody will hit them with a clue stick which will 
make them comprehend what they are doing :(


Ralf

Re: Fwd: Build Error (Job 9114): desmume-0_9_7-1_fc15 on fedora-development-rpmfusion_free

[Ralf Corsepius]

On 02/27/2011 06:45 PM, Andrea Musuruane wrote:

Hi all,
 I can't understand why this job fails on RPM Fusion buildsys. The
RPM is built fine with mock fedora-rawhide-x86_64-rpmfusion_free and
fedora-rawhide-x86_64 profiles. Can somebody help? Thanks.



undefined reference to `GTK_WIDGET_REALIZED'
/usr/lib/gcc/i686-redhat-linux/4.6.0/../../../libgtkglext-x11-1.0.so:
undefined reference to `GTK_WIDGET_TOPLEVEL'
/usr/lib/gcc/i686-redhat-linux/4.6.0/../../../libgtkglext-x11-1.0.so:
undefined reference to `GTK_WIDGET_NO_WINDOW'


Gtk's API was changed in Fedora 15. These symbols were deprecated in Gtk 
for some time and now have been removed from Fedora's Gtk.


Have a look into the src.rpm of gtkglext-1.2.0-14, (Currently stuck in 
Fedora QA's silly delay queue)

[https://admin.fedoraproject.org/updates/gtkglext-1.2.0-14]
for details of how a similar breakdown was fixed.

Ralf

Re: Missing freetype-freeworld-0:2.4.2-3.fc14.i686 update

[Ralf Corsepius]

On 11/22/2010 03:19 PM, Ralf Corsepius wrote:

Seems to me, as if somebody has pushed an update of
freetype-freeworld but has missed the fact that this package
is multilibbed:

# repoquery -qa 'freetype-freeworld*'
freetype-freeworld-0:2.4.2-2.fc14.i686
freetype-freeworld-0:2.4.2-3.fc14.x86_64

This triggers a defect in yum, which causes it to become confused:

# yum update

[...]


Please fix.


Whoever did it, thanks for fixing this.

Ralf

Missing freetype-freeworld-0:2.4.2-3.fc14.i686 update

[Ralf Corsepius]

Seems to me, as if somebody has pushed an update of
freetype-freeworld but has missed the fact that this package
is multilibbed:

# repoquery -qa 'freetype-freeworld*'
freetype-freeworld-0:2.4.2-2.fc14.i686
freetype-freeworld-0:2.4.2-3.fc14.x86_64

This triggers a defect in yum, which causes it to become confused:

# yum update
Loaded plugins: fastestmirror, presto, refresh-packagekit, 
remove-with-leaves

Loading mirror speeds from cached hostfile
 * fedora: ftp.halifax.rwth-aachen.de
 * rpmfusion-free: mirror.andreas-mueller.com
 * rpmfusion-free-updates: mirror.andreas-mueller.com
 * updates: mirror.leaseweb.com
Setting up Update Process
Resolving Dependencies
-- Running transaction check
-- Processing Dependency: libfreetype.so.6 for package: 
AdobeReader_enu-9.4-1.i486
-- Processing Dependency: libfreetype.so.6 for package: 
gtk2-engines-2.20.1-2.fc14.i686
-- Processing Dependency: libfreetype.so.6 for package: 
fontconfig-2.8.0-2.fc14.i686
-- Processing Dependency: libfreetype.so.6 for package: 
libXft-2.1.14-1.fc13.i686
-- Processing Dependency: libfreetype.so.6 for package: 
PackageKit-gtk-module-0.6.9-4.fc14.i686
-- Processing Dependency: libfreetype.so.6 for package: 
pango-1.28.1-4.fc14.i686
-- Processing Dependency: libfreetype.so.6 for package: 
gtk2-2.22.0-1.fc14.1.i686
-- Processing Dependency: libfreetype.so.6 for package: 
libcanberra-gtk2-0.25-4.fc14.i686
-- Processing Dependency: libfreetype.so.6 for package: 
flash-plugin-10.1.102.65-release.i386
-- Processing Dependency: libfreetype.so.6 for package: 
nspluginwrapper-1.3.0-14.fc14.i686
-- Processing Dependency: libfreetype.so.6 for package: 
cairo-1.10.0-2.fc14.i686

--- Package freetype-freeworld.x86_64 0:2.4.2-3.fc14 set to be updated
-- Running transaction check
--- Package freetype.i686 0:2.4.2-4.fc14 set to be installed
-- Finished Dependency Resolution

Dependencies Resolved

===
 Package ArchVersion 
  Repository   Size

===
Updating:
 freetype-freeworld  x86_64  2.4.2-3.fc14 
  rpmfusion-free-updates  317 k

Installing for dependencies:
 freetypei6862.4.2-4.fc14 
  updates 350 k


Transaction Summary
===
Install   1 Package(s)
Upgrade   1 Package(s)

Total download size: 667 k
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 667 k
(1/2): freetype-2.4.2-4.fc14.i686.rpm 
| 350 kB 00:00
http://mirror.andreas-mueller.com/pub/rpmfusion/free/fedora/updates/14/x86_64/freetype-freeworld-2.4.2-3.fc14.x86_64.rpm: 
[Errno 14] HTTP Error 404 : 
http://mirror.andreas-mueller.com/pub/rpmfusion/free/fedora/updates/14/x86_64/freetype-freeworld-2.4.2-3.fc14.x86_64.rpm 


Trying other mirror.
(2/2): freetype-freeworld-2.4.2-3.fc14.x86_64.rpm 
| 317 kB 00:00

---
Total 
   689 kB/s | 667 kB 00:00

Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating   : freetype-freeworld-2.4.2-3.fc14.x86_64 
1/2
  Installing : freetype-2.4.2-4.fc14.i686 
2/2

freetype-freeworld-2.4.2-2.fc14.i686 was supposed to be removed but is not!

Dependency Installed:
  freetype.i686 0:2.4.2-4.fc14 



Updated:
  freetype-freeworld.x86_64 0:2.4.2-3.fc14 



Complete!


Please fix.

Ralf

Re: you missed one

[Ralf Corsepius]

On 11/19/2010 09:55 PM, valent.turko...@gmail.com wrote:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=1527

mlt package is missing from rpmfusion-free fedora 14 repo.


... and perl-IP-Country needs a rebuilt for fedora 14 and its perl-5.12.0:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=1522

Ralf

Re: rpmfusion and noarch subpackages

[Ralf Corsepius]

On 07/02/2010 08:13 AM, Hans de Goede wrote:

Hi all,

Does $subject work? (can the push scripts handle it ?).
Related:
http://bugzilla.rpmfusion.org/show_bug.cgi?id=1310


Well, in this case the packaging is broken:

# diff -Naur 
i386/usr/share/gtk-doc/html/gst-plugins-ugly-plugins-0.10/ch01.html 
x86_64/usr/share/gtk-doc/html/gst-plugins-ugly-plugins-0.10/ch01.html
--- i386/usr/share/gtk-doc/html/gst-plugins-ugly-plugins-0.10/ch01.html 
2010-06-14 14:31:48.0 +0200
+++ 
x86_64/usr/share/gtk-doc/html/gst-plugins-ugly-plugins-0.10/ch01.html 
2010-06-14 14:15:22.0 +0200

@@ -21,7 +21,7 @@
 /tr/table
 div class=chapter title=gst-plugins-ugly Elements
 div class=titlepagedivdivh2 class=title
-a name=id2713711/agst-plugins-ugly Elements/h2/div/div/div
+a name=id1255571/agst-plugins-ugly Elements/h2/div/div/div

These docs use some id's
= These packages can neither be noarch nor be installed in parallel.
== This is a packaging bug

The real fix would be somehow remove these ids or to make them 
deterministic (== identical).


Ralf

Re: rpmfusion and noarch subpackages

[Ralf Corsepius]

On 07/02/2010 08:55 AM, Chen Lei wrote:

I think you'd better to add noarch to  -docs subpackage to avoid
multilib conflict.

Well, yes, this would be a short term work-around to circumvent this issue.

The real issue however is upstream trying to install build-dependent 
(non-deterministically built) packages into noarch subdirs.


I.e. they should fix the way they generate these files rsp. the tools 
they are using should be improved (I haven't checked which tools are 
being used)


In the past, we've had a similar case with doxygen. They had added 
timestamps to the docs they generated. Fortunately they improved it upon 
Fedora's request.


Ralf

Re: Non-commercial redistributable game data

[Ralf Corsepius]

On 05/19/2010 06:52 AM, Kevin Kofler wrote:

Ralf Corsepius wrote:

I have to vehemently disagree. What RH has done with the firmware is
having betrayed the OSS community, by claiming Firmware is not SW.
Though it has improved the uneducated user's experience this was a
slap into the face of OSS-developers.


Unfortunately, you'll be surprised by how much stuff actually requires
proprietary firmware to work. :-(

I am not surprized :)

 For example, ALL OpenGL drivers, at least

for contemporary hardware, require proprietary firmware to work at all.


This issue actually isn't new at all (Linux veterans may recall the 
Adaptec case). It applies to almost all smart/flexible add-on/external 
devices.



Another important thing: most hardware which does not require firmware
just has this firmware burned into a ROM.
Exactly - I recall times, people were burning BIOSes to ROMS to upgrade 
them ;)



Unfortunately, there are very few devices with genuinely Free firmware (and
no, some binary-only hex array claiming to be GPL isn't Free,
Depends - Certainly commented asm is better readable  but in some 
cases hex arrays (machine code) are not unlikely to be the real 
source of firmware.


I've written and maintained such code for embedded systems myself ;)


We have a long way to go… :-(
Yes, ... and Fedora's double-standards are not helping change the 
situation :(


Ralf

Re: Any remaining things to be done before the final F13 release repos can get created?

[Ralf Corsepius]

On 05/18/2010 11:29 AM, Thorsten Leemhuis wrote:

Hi!

Just a heads up: I plan to create the final F13 release repos over the
next few days by basically moving everything from the updates repos to
the Everything repos(¹). If you want a updated package in there please
tell me until Thursday evening, otherwise it might be to late.


free updates carries several *.fc14.rpms.

Ralf

Re: Non-commercial redistributable game data

[Ralf Corsepius]

On 05/17/2010 12:55 PM, Hans de Goede wrote:

Hi,

Jonathan Dieter wrote:

I've noticed a number of games whose content is distributable as long as
it's distributed for free. A few of those games have ended up in Fedora
but use autodownloader to download the game data.

I really don't like this method because, at least as I understand it,
the game data ends up in the user's home directory. If another user
wants to play the game, they have to redownload the data.

What is the feasibility of providing -data packages in rpmfusion-nonfree
that would provide the data for said games, so the data could be
installed system-wide? Can autodownloader (cc'ing autodownloader
maintainer) check for game data availability before downloading the data
off the internet?


Well all autodownloader using games use a .sh script to launch
autodownloader
when the data is not present in the expected location, modifying those
scripts
to check for game-data under say /usr/share/%{name} first should not be
a problem.

Patches for that (together with rpmfusion packages of the data, so that
the whole
can be tested together) would definitely be welcome. I'm also always open
to co-maintainers for the Fedora packages in question.

Do I understand this correctly?
* FESCO has a approved an installer which circumvents rpm?

* This installer is installing to /usr/share?

Ralf

Re: Non-commercial redistributable game data

[Ralf Corsepius]

On 05/17/2010 02:39 PM, Rahul Sundaram wrote:

On 05/17/2010 06:03 PM, Ralf Corsepius wrote:
   

Do I understand this correctly?
* FESCO has a approved an installer which circumvents rpm?

* This installer is installing to /usr/share?
 

That seems to be a misunderstanding.  Autodownloader downloads data to
your home directory.

OK, it opens up the gates to worms and viruses.

That's not as bad as I had presumed, nevertheless *BAD*.


   Not /usr/share.


OK. This would not fly anywhere.

Ralf

Re: Non-commercial redistributable game data

[Ralf Corsepius]

On 05/17/2010 02:45 PM, Rahul Sundaram wrote:

On 05/17/2010 06:13 PM, Ralf Corsepius wrote:
   

On 05/17/2010 02:39 PM, Rahul Sundaram wrote:
 

On 05/17/2010 06:03 PM, Ralf Corsepius wrote:

   

Do I understand this correctly?
* FESCO has a approved an installer which circumvents rpm?

* This installer is installing to /usr/share?

 

That seems to be a misunderstanding.  Autodownloader downloads data to
your home directory.
   

OK, it opens up the gates to worms and viruses.
 

Can you explain how?  Autodownloader has a hash of the files that it
downloads and verifies them.
   
$HOME == automated arbitrary access to arbitrary user data == arbirary 
option to install maliculous programs (viruses, spyware etc.).

Re: Non-commercial redistributable game data

[Ralf Corsepius]

On 05/17/2010 03:00 PM, Rahul Sundaram wrote:

On 05/17/2010 06:24 PM, Ralf Corsepius wrote:



downloads and verifies them.


Can you explain how?  Autodownloader has a hash of the files that it
$HOME == automated arbitrary access to arbitrary user data == arbirary
option to install maliculous programs (viruses, spyware etc.).


It is not arbitrary and the user is prompted to download the data.  The
data is verified against a hash.

You mean the forged hash, referring to the self-modifiying data inside.


 Did you even try out autodownloader
and understand how it works?  Doesn't seem like it at all.

No, I haven't, and I certainly will not try it.


 I highly recommend doing that.
I highly recommend people to package packages into rpms on rpm-based 
distros instead of trying to out-smart themselves (which is what I fell 
currently is happening).

Re: Non-commercial redistributable game data

[Ralf Corsepius]

On 05/17/2010 03:08 PM, Rahul Sundaram wrote:

On 05/17/2010 06:33 PM, Ralf Corsepius wrote:
   

  Did you even try out autodownloader
and understand how it works?  Doesn't seem like it at all.
   

No, I haven't, and I certainly will not try it.
 

.
I don't disagree that RPM packaged data is better but claiming that it
is a attack vector for trojans and viruses without any understanding of
how it works cannot be taken seriously.
Even rpms are an attack vector. They are not necessarily safer than 
packages shipped via other means.




 You don't have to try it out
to understand how it works. So that is not a valid reason either.
   
My point is a bit different: I consider this mechanism to be a way to 
*circumvent* rpm as means of packaging and it to be a way of encourage 
*sloppyness*, *lazyness* and *carelessness*, which endangers Fedora's users.



If FESCO has a littel understanding, they would have noticed that 
mechanically packaging game data into rpms and to ship them via  repos 
is trivial. There is no need to add another mechanism for shipping 
packages and to endanger users from the security risks this comes 
attached with.


Or differently: One fundamental key of rpm-based distros safety and 
consistency has been not to allowing other means of installation.


Ralf

Re: Non-commercial redistributable game data

[Ralf Corsepius]

On 05/17/2010 04:34 PM, Jonathan Dieter wrote:

On Mon, 2010-05-17 at 15:36 +0200, Ralf Corsepius wrote:

My point is a bit different: I consider this mechanism to be a way to
*circumvent* rpm as means of packaging and it to be a way of encourage
*sloppyness*, *lazyness* and *carelessness*, which endangers Fedora's users.

If FESCO has a little understanding, they would have noticed that
mechanically packaging game data into rpms and to ship them via  repos
is trivial. There is no need to add another mechanism for shipping
packages and to endanger users from the security risks this comes
attached with.

Or differently: One fundamental key of rpm-based distros safety and
consistency has been not to allowing other means of installation.


Ralf, I think we all agree with the fact that it is optimal to install
game data as an rpm.  The problem is that, for any game that uses
autodownloader, the data *cannot* be packaged in Fedora because of
license reasons.


Rpmfusion can easily package them.

RH or Fedora are not required to be involved into this at all.

Ralf

Re: Non-commercial redistributable game data

[Ralf Corsepius]

On 05/17/2010 04:56 PM, Lubomir Rintel wrote:

On Mon, 2010-05-17 at 16:45 +0200, Ralf Corsepius wrote:

On 05/17/2010 04:34 PM, Jonathan Dieter wrote:

On Mon, 2010-05-17 at 15:36 +0200, Ralf Corsepius wrote:

My point is a bit different: I consider this mechanism to be a way to
*circumvent* rpm as means of packaging and it to be a way of encourage
*sloppyness*, *lazyness* and *carelessness*, which endangers Fedora's users.

If FESCO has a little understanding, they would have noticed that
mechanically packaging game data into rpms and to ship them via  repos
is trivial. There is no need to add another mechanism for shipping
packages and to endanger users from the security risks this comes
attached with.

Or differently: One fundamental key of rpm-based distros safety and
consistency has been not to allowing other means of installation.


Ralf, I think we all agree with the fact that it is optimal to install
game data as an rpm.  The problem is that, for any game that uses
autodownloader, the data *cannot* be packaged in Fedora because of
license reasons.


Rpmfusion can easily package them.

RH or Fedora are not required to be involved into this at all.


Guess what, neither Fedora nor Red Hat is required to be involved in
anything.

If I understand the FESCO's was a trade-off; there's a lot of free
software games that would be useless with a little help of
badly-licensed pieces and FESCO decided that Fedora's mission is better
accomplished if the games are as easily brought into state of being as
easily installable and playable by a common user as it can be.

That is not that uncommon. Ever heard of firmware blobs for the device
drivers?
Yes, it's the stuff RH and FESCO had allowed to break the principles of 
FLOSS with, Fedora once was based on, based on the claim firmware is 
no SW - Any firmware developer will tell you this claim is simply untrue!



Sure, there's a difference that those, even though lacking the
source code, are distributable and this can be RPM-ized, but that's a
different issue and was discussed around here already. The principle
remains the same; a bit of a trade off for a rather big improvement.


Which improvements? Locally installing improperly packaged stuff, and 
reinvent mechanisms to assure consistencies, which rpm already provides 
if this stuff was properly packages as rpms?


I really see no need for this autodownloader - Package it it rpms, if 
their licenses permits it or leave this stuff alone.



Be
it a greatly improved hardware support, or improved experience of game
players.
I have to vehemently disagree. What RH has done with the firmware is 
having betrayed the OSS community, by claiming Firmware is not SW.
Though it has improved the uneducated user's experience this was a 
slap into the face of OSS-developers.


What you now are doing now, to me is throwing overboard system 
consistency, packaging etc. Certainly, any arbitrary user has the 
liberty to install any arbitrary binary blobs into his HOME (if he knows 
how to do so), but doing so automatically is simply careless.


Ralf

Re: NEED a SPONSOR to add me to the packager group

[Ralf Corsepius]

On 03/08/2010 01:59 PM, Chen Lei wrote:

Hi all,

My rpmfusion FAS name is supercyper, the same as my fedora FAS name.
I'm already a fedora packager, but I'm not rpmfusion packager yet. Could anyone 
add me to the rpmfusion packager group, so that I can do some review for some 
rpmfusion packages?

You don't need an rpmfusion account for performing a review.

Ralf

Re: [Bug 1030] Review request: xbmc - Media center

[Ralf Corsepius]

On 02/23/2010 10:54 PM, Nicolas Chauvet wrote:

2010/2/23 David Timmsdti...@iinet.net.au


On 24/02/10 07:27, RPM Fusion Bugzilla wrote:


http://bugzilla.rpmfusion.org/show_bug.cgi?id=1030

--- Comment #100 from Alex Lancasteral...@users.sourceforge.net



Yep: -12 is the most recent.



Hi, I would like to suggest that this package review (which has really been
more of a packaging development bug) be closed, and a new one requested.
(close duplicate after create new bug)

This would keep the normal review stuff together, and uncluttered by the
preliminary package development work.

Anyone else agree/disagree ?

Cheers,
David Timms.


I don't see any problem with keeping the same bug report for the review,

Agreed. IMO, it's simply a case of a complicated review.


That development side was fully part of the review process.
I don't see any reason to split, specially as this review seems exemplary of
what work need to be achieved if a package doesn't comply with our
guidelines.

Once that said, I guess a sum-up of what remain to be worked on, would be
welcome for a new comer.

OK, an attempt of a short summary:


* Technically: *-12 doesn't build for FC13 ;)

- An API change between rpmfusion's FC12 and FC13's ffmpeg breaks xbmc.
- xbmc is victim of the DSO changes in FC13.
- There is a subtile configure script bug somewhere causing it to 
(silently) not to work for FC13.


I have dirty hacks addressing the 1st and 2nd issues pending, but am 
still investigating the latter, yet. Could be one these autoreconf is 
harmful cases, could also be a side-effect of the DSO-changes, could be 
something else, ... I don't know yet.



* Usability-wise:
- Verify that python works sufficiently.
There have been reports that xbmc's python scripts (python2.4) don't 
work on Fedora (python2.6). I haven't see any such python breakdown yet, 
so I don't know how to reproduce such breakdown.


- Decide about what to do with xbmc-standalone.
IMO, it's dysfunctional.

- Decide about what to do with /usr/bin/xbmc's core dump feature.
To me, it's nothing but silly.


* Perform a legal review.

- AFAICT, even if putting patent issues aside, xbmc is not [L]GPL'ed, 
because it contains subpackages/libraries which are not 
[L]GPL-compatible.  The original xbmc code certainly is free, but I am 
having strong doubts if all of the libraries they have bundled, are 
(e.g. GoAHead, UnRar).


In Fedora, I would reject this package for improper licensing and/or 
delegate it for legal review to FE-LEGAL. No idea, about what rpmfusion 
wants to do about it.


- One detail: xbmc contains fonts, which suspiciously look like bundled 
msttcorefonts, but I haven't checked the details, yet.



* Packaging-wise/FPG-compliance-wise: xbmc contains many bundled 
libraries.


Alex, Rolf and I already removed some of them, but one would have to 
check further of them can be replaced with unbundled versions and 
which of them can't because upstream xbmc has hacked them up.


Ralf

Re: HandBrake in rpmfusion? (continued from bug #679)

[Ralf Corsepius]

On 11/16/2009 05:35 AM, Bernard Johnson wrote:

On 11/15/2009 09:01 PM, Justin wrote:

The biggest problem with renaming it, imo, is that a lot of users will
be looking for HandBrake specifically and may not know. This is
especially true because HandBrake is not nearly as ubiquitous as
Firefox. That was big news and something that got around quickly. I
don't think this will be.


Yes, I agree. Besides the work of re-branding,
Unless their stuff is a registered trademark there is no need to rebrand 
anything.


You would simply ship a HandBrake with Fedora-specific patches 
applied. This would not even be a fork, this is ordinary packaging.


Ralf

Re: HandBrake in rpmfusion? (continued from bug #69)

[Ralf Corsepius]

On 11/16/2009 05:40 AM, Bernard Johnson wrote:

On 11/15/2009 09:14 PM, Orcan Ogetbil wrote:

3. Don't package it

I vote for 3.


+1 (obviously, I closed the bug)


Let them distribute their broken stuff themselves, unless if someone in
rpmfusion has the stomach to handle the issues.


Honestly, their stuff is pretty sane - it's just that they are so
bleeding edge,

Really?

If so, then the standard approach to packaging would be to wait with 
packaging an application until the libraries' upstreams have caught up.


Or differently: If a distro doesn't provide the requirements a package 
requires, then this package can't be included into a distro.


The standard approach in such cases would be to resort to packaging 
older versions of the application.


Ralf

Re: HandBrake in rpmfusion? (continued from bug #679)

[Ralf Corsepius]

On 11/16/2009 06:07 AM, Bernard Johnson wrote:

On 11/15/2009 10:04 PM, Ralf Corsepius wrote:

You would simply ship a HandBrake with Fedora-specific patches
applied. This would not even be a fork, this is ordinary packaging.


That wasn't at all why I even brought it up - it was merely a way to
disassociate the package from upstream (read the thread and IRC logs to
see why).


Disassociating from upstreams is in nobody's interest.

Ralf

Re: Downtime due to DNS configuration error

[Ralf Corsepius]

On 10/06/2009 12:03 PM, Matthias Saou wrote:

Hi,

Last night, I made some DNS configuration changes using Gandi's web
interface. I shouldn't have touched rpmfusion.* domains, but I somehow
managed to do so (I honestly don't know how, though), and pointed
rpmfusion.org to a wrong zone file.

Someone notified me a few minutes ago about this by IM since I hadn't
yet checked my emails for today, and it's now fixed.


Is it?

For me, www.rpmfusion.org seems to work again, but 
mirrors.rpmfusion.orig, download1.rpmfusion.org and cvs.rpmfusion.org 
still don't.


DNS delays showing their effect or is there still something broken?

Ralf

Re: Downtime due to DNS configuration error

[Ralf Corsepius]

On 10/06/2009 12:54 PM, Adrian Reber wrote:

On Tue, Oct 06, 2009 at 12:35:28PM +0200, Ralf Corsepius wrote:

On 10/06/2009 12:03 PM, Matthias Saou wrote:

Last night, I made some DNS configuration changes using Gandi's web
interface. I shouldn't have touched rpmfusion.* domains, but I somehow
managed to do so (I honestly don't know how, though), and pointed
rpmfusion.org to a wrong zone file.

Someone notified me a few minutes ago about this by IM since I hadn't
yet checked my emails for today, and it's now fixed.


Is it?

For me, www.rpmfusion.org seems to work again, but
mirrors.rpmfusion.orig, download1.rpmfusion.org and cvs.rpmfusion.org
still don't.

DNS delays showing their effect or is there still something broken?


DNS seems to be working again and after a restart of httpd I see lots of
people accessing the mirrorlist again. So that part looks good again
from here.


Wild guess: I guess, Thias managed to poison dns/bind-caches.

dig +trace [mirrors|...].rpmfusion.org
brought them back for me ;(

Ralf

Re: mplayer ffmpeg with VDPAU Support

[Ralf Corsepius]

Kevin Kofler wrote:

Felix Kaechele wrote:

Now I wanted to know if it would be possible to
include VDPAU support in packages in RPMFusion?
One main issue I'd see is that VDPAU support would make the packages
that support it nonfree wether or not they are basically free, since
they would have a BuildRequirement on xorg-x11-drv-nvidia-devel.


That's not possible, we need ffmpeg in RPM Fusion free (most of RPM Fusion
free depends on it!), it can't BR stuff from nonfree.


... but you could use non-free to replace packages from free ...

It's essentially the same as to replace packages from Fedora with 
RPMFusion packages, only that it would be RPMFusion replacing itselves ;)

Re: mplayer ffmpeg with VDPAU Support

[Ralf Corsepius]

Nicolas Chauvet wrote:

2009/3/4 Andrea Musuruane musur...@gmail.com:

On Wed, Mar 4, 2009 at 1:23 PM, Ralf Corsepius rc040...@freenet.de wrote:

... but you could use non-free to replace packages from free ...

It's essentially the same as to replace packages from Fedora with RPMFusion
packages, only that it would be RPMFusion replacing itselves ;)

It is RPM Fusion policy NOT to replace packages from Fedora.


We do not replace package, we replace library using the system dynamic linker.


The result is essentially the same:
- Non deterministic system behavior
- Potential NEVR and file conflicts and NEVR races.

Ralf

Re: mplayer ffmpeg with VDPAU Support

[Ralf Corsepius]

Nicolas Chauvet wrote:

2009/3/4 Ralf Corsepius rc040...@freenet.de:

Nicolas Chauvet wrote:

2009/3/4 Andrea Musuruane musur...@gmail.com:

On Wed, Mar 4, 2009 at 1:23 PM, Ralf Corsepius rc040...@freenet.de
wrote:

... but you could use non-free to replace packages from free ...

It's essentially the same as to replace packages from Fedora with
RPMFusion
packages, only that it would be RPMFusion replacing itselves ;)

It is RPM Fusion policy NOT to replace packages from Fedora.


We do not replace package, we replace library using the system dynamic
linker.

The result is essentially the same:

I was trying to say it was not, and tried to say why, but it was snaped

- Non deterministic system behavior

Can you elaborate a little bit ?


Quite simple: Your *.so's suffer from different bugs than the version in 
Fedora, your *.so's provide different features than the packages in 
Fedora = Different application behavior, function-wise and bugs-wise.


Whether you only replace the libs or even the applications doesn't 
matter much.


The only real difference is, when only replacing the *.so's you don't 
have to care about consistency wrt. applications (installation paths, 
number of applications etc.).



Remember that wxsvg-freeworld have been rejected because the
with_ffmpeg broke the ABI with ffmpeg_less version provided in fedora.
Do I understand correctly? RPMFusion has decided not provide the ffmpeg 
enabled wxsvg?


What shall I think of this?


- Potential NEVR and file conflicts and NEVR races.

Possible Do you have cases studies ?

The kmods vs. akmod vs. kernel issues are such a case.

Ralf

Re: [Bug 195] Review request: perl-Crypt-IDEA - Perl interface to IDEA block cipher

[Ralf Corsepius]

Going off-bugzilla.

RPM Fusion Bugzilla wrote:

http://bugzilla.rpmfusion.org/show_bug.cgi?id=195





--- Comment #10 from Michael Schwendt mschwe...@gmail.com  2009-01-18 
12:49:21 ---
The original rationale for recommending install -p and cp -p when
installing files manually (inside the spec file e.g.) has been in preserving
timestamps for _prebuilt_ files in tarballs. Such as various forms of
documentation files.



It is considered helpful by many package users, because they can judge about
the age of documentation files simply by checking timestamps. Particularly
helpful with but not limited to larger pdf/ps files and html trees. No need to
revisit such files after package updates, if the documentation is still
unchanged since 2001, for example, and other files are several months old, too.
User would cd /usr/share/doc/... and quickly notice that only a README file
has changed for this update.


Provided the fact many pdf/ps/man files are _generated_ (doxygen, 
texinfo, pod2man), this rationale is of very limited use, as well as a 
simple INSTALL=install -p would not help in many occasions.



A few corner-cases have been found where install -p helped,

Correct, there have been _very few_ such cases.

Off-head I don't recall any ;)


I think related to
.rpmnew creation of config files just because the mtime changed (and not just
the checksum).


.rpmnew's are being generated for %config files. Handling them correctly 
is rpm's job. And yes, IIRC, rpm once had been broken wrt. them.



Some reviewers have expanded the recommendation to use install -p ... to also
run make install DESTDIR=$RPM_BUILD_ROOT INSTALL=install -p, which I think
is somewhat over the top


Agreed, but I'd express it a bit harder: Enforcing such a rule 
demonstrates a reviewer's lack of technical skills.


He should at least examine whether a package recognises INSTALL (All 
automake based ones do, most others don't), rsp. whether preserving 
would make any sense in a particular package.


In most cases, it doesn't.


even if covers a few more prebuilt files. Some
tarballs mix cp/install and mkdir/install, so one would need to switch to cp
-p for the full show.

additionally there are other means of generating files ...

E.g. perl modules typically copy around their sources (lib/blib) during 
builds, generate man-pages on the-ply (using pod2man) etc.



So, conclusively: Historically it has only been pedantic eye-candy (albeit
considered helpful by our users). If nowadays there is knowledge that it
actually fixes anything else, please document that.
Actually, I would finally see any actual bug, this install -p fixes, 
these days.


In the past, have been some case, but AFAICT, all of them actually have 
been side-effects of bugs elsewhere (e.g. rpm).


Ralf

Re: [Bug 151] Review Request: systemc - Design and verification language for Hardware

[Ralf Corsepius]

On Mon, 2008-12-15 at 23:51 +0100, RPM Fusion Bugzilla wrote:
 http://bugzilla.rpmfusion.org/show_bug.cgi?id=151

 --- Comment #19 from Orcan Ogetbil orcanba...@yahoo.com  2008-12-15 
 23:51:51 ---
 (In reply to comment #18)
  (In reply to comment #16)
   As I noted before ls is not intended to be used in shell scripts.
  No idea, what makes you think this. 
  
  It's perfectly legitimate to use ls in shell scripts.
  
 
 Just google bash guide or something similar and click on any of the results.
 I'm sure you will see that they will try to discourage you from parsing ls
 outputs. It's considered bad programming.
 
 For instance see (scroll down to NOTE:):
 http://wooledge.org:8000/BashGuide#BashGuide.2BAC8-TheBasics.2BAC8-CommandsAndArguments.CommandsAndArguments

What this author says is entire BS.

1. ls is standardized by POSIX etc. 
2. It is not intended to be used only for producing human-readable
results.

Furthermore, we are talking about building RPMs on Linux (i.e. in well
defined environment), not on general portability of ls (which, unlike
you and the author of the article above claim, exists).


Ralf

Re: libdvdcss,again

[Ralf Corsepius]

On Sat, 2008-12-13 at 21:14 +0100, Kevin Kofler wrote:
 Andrea Musuruane wrote:
  I really hope this is the last time this is asked.
 
 I think you know as well as me or everyone else what the only way this
 question is going to stop being asked is.
No. This questions will only stopp, when some court confirms or
disapproves the suspected legal threats.

Re: the libdvdcss issue

[Ralf Corsepius]

On Tue, 2008-11-18 at 12:18 +0100, Richard Körber wrote:

 For me it means that if RPMfusion is offering software that is illegal in
 Germany, 
reference?

To my knowledge, libdvdcss legal position is questionable and unclear in
Germany, but so for has not been proven illegal.

Ralf

Re: rpmfusion-free-rawhide repos broken/invalid repodata?

[Ralf Corsepius]

On Fri, 2008-11-07 at 08:13 +0100, Adrian Reber wrote:
 On Fri, Nov 07, 2008 at 07:46:26AM +0100, Adrian Reber wrote:
  On Fri, Nov 07, 2008 at 03:51:00AM +0100, Ralf Corsepius wrote:
   On Thu, 2008-11-06 at 20:57 +0200, مؤيد السعدي wrote:
it's the mirror manager and it's supposed to be fixed

https://bugzilla.rpmfusion.org/show_bug.cgi?id=121#c5
   Well, doesn't work for me.
   
   Things appear as broken as before.
  
  Yes it broke again. x86_64 is for some reason the only architecture
  which does not have this error. I am looking into it.
 
 Please try it again.
 
 I have put in simple workaround which can be hopefully removed once the
 development repositories have the same layout as the rest.
Well, closer, but no cigar ;)

When not touching /etc/yum.repos.d/*.repo, yum continues to expose the
broken behavior (seemingly it continues using it's (broken) cache).

When changing the *.repo to using baseurl=download1 instead
of mirrorlist=... yum starts complaining
Not using downloaded repomd.xml because it is older than what we have:
  Current   : Thu Nov   6 14:00:19 2008
  Downloaded: Thu Nov   6 14:00:14 2008

When deleting /var/cache/yum/rpmfusion-free-rawhide/*, things appear
functional again.

Ralf

totem/gstreamer/ffmpeg issues

[Ralf Corsepius]

Hi,

I don't know what has changed (and whose fault it might be), but today's
rpmfusion/rawhide update broke totem video play back badly for me 
on an F10/rawhide + rpmfusion-free + rpmfusion-nonfree system.

E.g. I am observing 
* selinux alerts related toten-video-thumbnailer and totem itself having
selinux problems with libavformat
* playback of many (all?) *.flv's and *.mp4's has stopped working (So
far, I haven't found any file for which it works).
...

All I can say: rpmfusion things used to work when I tried last weekend,
and now don't do so anymore.

Ralf

Re: totem/gstreamer/ffmpeg issues

[Ralf Corsepius]

On Tue, 2008-11-04 at 21:04 +0100, Hans de Goede wrote:
 Ralf Corsepius wrote:
  Hi,
  
  I don't know what has changed (and whose fault it might be), but today's
  rpmfusion/rawhide update broke totem video play back badly for me 
  on an F10/rawhide + rpmfusion-free + rpmfusion-nonfree system.
  
  E.g. I am observing 
  * selinux alerts related toten-video-thumbnailer and totem itself having
  selinux problems with libavformat
  * playback of many (all?) *.flv's and *.mp4's has stopped working (So
  far, I haven't found any file for which it works).
  ...
  
  All I can say: rpmfusion things used to work when I tried last weekend,
  and now don't do so anymore.
  
 
 This is most likely caused by the new ffmpeg which has cpu specific 
 optimalizations turned on for the first time, try manualy removing the 
 version 
 under /usr/lib[64]/sse2, that should make you fallback to the old no cpu 
 specific optimalizations version.

The initial sealert is on sse2/libavcodec.so.51.71.0.

Manually removing /usr/lib/sse2/libavcodec.so.51.71.0 triggers a similar
sealert on /usr/lib/sse2/libavutil.so.49.10.0

Removing both
/usr/lib/sse2/libavcodec.so.51.71.0
/usr/lib/sse2/libavutil.so.49.10.0
brings totem back into business.

 Also try turning of selinux (setenforce 0) to see if that fixes things,
This also helps ;)

Another observation:
# ls -Z libavutil.so.49.10.0 sse2/libavutil.so.49.10.0 \
libavcodec.so.51.71.0 sse2/libavcodec.so.51.71.0 

-rwxr-xr-x  root root system_u:object_r:textrel_shlib_t:s0
libavcodec.so.51.71.0
-rwxr-xr-x  root root system_u:object_r:textrel_shlib_t:s0
libavutil.so.49.10.0
-rwxr-xr-x  root root system_u:object_r:lib_t:s0
sse2/libavcodec.so.51.71.0
-rwxr-xr-x  root root system_u:object_r:lib_t:s0
sse2/libavutil.so.49.10.0

= This seems inconsistent to me. I would suspect something is wrong
with these libraries' SELinux setup.

The sealerts recommend to
chcon -t textrel_shlib_t /usr/lib/sse2/libavcodec.so.51.71.0
chcon -t textrel_shlib_t /usr/lib/sse2/libavutil.so.49.10.0

and to
semanage fcontext -a -t \
textrel_shlib_t /usr/lib/sse2/libavcodec.so.51.71.0
semanage fcontext -a -t \
textrel_shlib_t /usr/lib/sse2/libavutil.so.49.10.0 

which also seem to remedy the issue.

= The SELinux rules for these library need to be extended.

 I'm not advocating this as a fix, merely suggesting doing this as a way to 
 debug this.
Well, my opinion on SELinux ... it causes more collateral damage than it
helps ;)

Ralf

Re: totem/gstreamer/ffmpeg issues

[Ralf Corsepius]

On Wed, 2008-11-05 at 03:22 +0100, Dominik 'Rathann' Mierzejewski wrote:
 On Tuesday, 04 November 2008 at 21:04, Hans de Goede wrote:
  Ralf Corsepius wrote:
  Hi,
  
  I don't know what has changed (and whose fault it might be), but today's
  rpmfusion/rawhide update broke totem video play back badly for me 
  on an F10/rawhide + rpmfusion-free + rpmfusion-nonfree system.
  
  E.g. I am observing 
  * selinux alerts related toten-video-thumbnailer and totem itself having
  selinux problems with libavformat
  * playback of many (all?) *.flv's and *.mp4's has stopped working (So
  far, I haven't found any file for which it works).
  ...
  
  All I can say: rpmfusion things used to work when I tried last weekend,
  and now don't do so anymore.
  
  This is most likely caused by the new ffmpeg which has cpu specific 
  optimalizations turned on for the first time, try manualy removing the 
  version under /usr/lib[64]/sse2, that should make you fallback to the old 
  no cpu specific optimalizations version.
 
 There are no separate SSE2-optimized binaries in x86_64 build. All x86_64
 CPUs have SSE2.
My rawhide testing machine is an Atom N270 [1], i.e. i686 ;)

Ralf
[1] Running rawhide only because FC9 doesn't run at all on this machine.

Re: totem/gstreamer/ffmpeg issues

[Ralf Corsepius]

On Tue, 2008-11-04 at 20:04 -0700, Conrad Meyer wrote:
 On Tuesday 04 November 2008 06:48:44 pm Dominik 'Rathann' Mierzejewski wrote:
  On Wednesday, 05 November 2008 at 03:24, Ralf Corsepius wrote:
   On Tue, 2008-11-04 at 21:04 +0100, Hans de Goede wrote:
Ralf Corsepius wrote:
 Hi,


  And costs up to 70% of performance.

 I'm not sure Intel Atom cpus *have* SSE2.
I haven't book-checked, but mine (an Atom N270) at least claims to have it:

cat /proc/cpuinfo 
...
flags   : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc
arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 xtpr lahf_lm
...

If it hadn't, ffmpeg would hardly work with SELinux disabled or the
other SELinux work-arounds enabled? :)

Ralf

Re: totem/gstreamer/ffmpeg issues

[Ralf Corsepius]

On Wed, 2008-11-05 at 03:48 +0100, Dominik 'Rathann' Mierzejewski wrote:

  = The SELinux rules for these library need to be extended.
 
 Feel free to add to my SELinux policy ticket I filed.
I just filed
https://bugzilla.redhat.com/show_bug.cgi?id=469992

Ralf

Re: Omega - Sudo for first user?

[Ralf Corsepius]

On Wed, 2008-10-01 at 23:12 +0530, Rahul Sundaram wrote:
 Jeroen van Meeuwen wrote:
  Rahul Sundaram wrote:
  Thorsten Leemhuis wrote:
  On 01.10.2008 16:43, Rahul Sundaram wrote:
 
  If I stuck this portion into the fedora-live initscript, it would 
  enable sudo for the first user entered during firstboot. Does this 
  seem like a sensible thing to do? Does anyone have the details 
  handy on modifying consolehelper as well?
 
  The official RPM Fusion spin should IMHO be a Fedora + add-on 
  packages and nothing else.
 
 
  Yes, we could do fancy things like enabling sudo by default and 
  hundred other things where Fedora sucks. But that's somethings that 
  is IMHO just as bad as replacing packages from Fedora (which we 
  don't do) 
  I kind of see your point but I think there is room for minor 
  improvements such as these.
 
  I think that if this improvement is worth the trouble, it should go 
  into the firstboot application (upstream), even if only as a 
  configurable firstboot option.
 Sure, there is no disagreement on the ideal path. There has been RFE's  
 (sometimes with patches) for similar things a long time.  The 
 traditional problem is a very diffused userbase where anything except 
 status quo tends to meet with opposition.

It's not not changing the status quo, it's a matter of experienced
users vs. newbies lacking the knowledge to understand the status quo.

   The recent change to add sbin to path being a recent example
  where somebody decides to go ahead and do 
 it anyway.
Correct, a masterpiece of where uneducated newbies are outsmarting
themselves and are throwing away well-thought out principles which have
developed over a long period of development for good reasons.

To me, this /sbin PATH thing is a regression and a Fedora mistake. 

Fortunately, it's unimportant enough to fret about it.

  Hopefully that happens with sudo as well.
Well, ... see above.

Ralf

Re: rpmfusion based spin

[Ralf Corsepius]

On Fri, 2008-08-29 at 07:09 +0530, Rahul Sundaram wrote:
 Andreas Thienemann wrote:

  Ohhh right, the .*Kit madness. Does PackageKit works nowadays? 
 Yes, it does
Define works. 

So far, I am having a lot of problems with PackageKit as well as
NetworkManager, ...

Ralf

Re: Import status livna, work from maintainers required

[Ralf Corsepius]

On Mon, 2008-08-18 at 13:06 +0200, Thorsten Leemhuis wrote:
 On 18.08.2008 12:51, Dominik 'Rathann' Mierzejewski wrote:
  On Monday, 18 August 2008 at 11:57, Dominik 'Rathann' Mierzejewski wrote:

  It's a patch.
 
 It's a compressed patch and CVS afaics doesn't handle binaries very well 
Patches need to be added cvs add -kb, otherwise chances are cvs could
corrupt them, when patches contain patterns which match cvs metatags
($Id$ etc.).

Ralf