Re: Mass rebuild for f26 is almost finished
On 25 March 2017 at 08:33, Nicolas Chauvet wrote: > I've retired sonic-visualiser-freeworld in RPM Fusion as the package > only rely on libmad which is now in fedora. > Also there is a new upstream for this package, so one needs to update > the package in fedora and properly obsoletes the -freeworld version. > The email notification for the change was not received so I expect > Michel Salim to be missing. > > I also know kwave which needs to be migrated to fedora for the same > reason (maintainer warned). > We should probably move traverso to the Fedora proper as well. However it's hard to spare time for it. More importantly I can't upgrade my machine beyond F24 because of [1]. I don't feel comfortable putting packages out there with zero testing on my side. Please feel free to retire it and/or handle the situation. Thanks, Orcan [1] https://bugzilla.redhat.com/show_bug.cgi?id=1352334 ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [kaffeine] Patch for gcc6 and cmake changes
On 29 June 2016 at 22:28, Mamoru TASAKA wrote:
> Hello, again:
>
>> 差出人: "Orcan Ogetbil"
>> On 29 June 2016 at 00:10, Mamoru TASAKA wrote:
>> > Hello:
>> >> 差出人: "Orcan Ogetbil"
>> >> On 27 June 2016 at 02:57, Leigh Scott wrote:
>> >> > commit ed8b668fc05a7f626d5d34e779f58be200b7884c
>> >> > Author: leigh123linux
>> >> > Date: Mon Jun 27 07:57:17 2016 +0100
>> >>
>> >> > +- char cmd[] = { 0xe0, 0x31, 0x6b, config->lnbNumber };
>> >> > ++ char cmd[] = { char(0xe0), 0x31, 0x6b,
>> >> > char(config->lnbNumber) };
>> >>
>> >> Hi, this looks like a compiler bug to me. I don't see anything
>> >> ambiguous in the first line. Are we sure the compilation error is the
>> >> intended behavior?
>> >>
>> >> Thanks,
>> >> Orcan
>> >>
>> >
>> > I guess kaffeine is C++ and converting 0xe0 (this is (int)224) to char is
>> > narrowing conversion, and implicit narrowing conversion on array
>> > initialization
>> > is forbidden with gcc6 (i.e. C++14), so now gcc now makes the original
>> > error.
>>
>> I see. That makes sense. But I think the problem is with
>> config->lnbNumber instead of 0xe0 (I didn't look into the source code,
>> this is my guess).
>> The standard [1] says (page 239):
>>
>> "A narrowing conversion is an implicit conversion
>> (7.4)
>> from an integer type or unscoped enumeration type to an integer type
>> that cannot represent all the
>> values of the original type, except where the source is a constant
>> expression whose value after integral
>> promotions will fit into the target type."
>>
>> Constant int 224 is within range for char as far as I know so it would
>> fit into char. Thus, if my interpretation is right, it should not be
>> considered narrowing conversion.
>
> Well, "char" is signed by default on x86_64, so char range is
> -128 <= char <= 127. So (int)224 is out of char range.
>
> Note that char is unsigned by default on arm, so
> char foo[] = {-1, -1}; fails with C++14 on arm (but not on x86_64).
>
Aha. That's the catch. My (wrong) interpretation was 224 could be
represented by 8 bits, I didn't think about signature.
Thanks folks,
Orcan
Re: [kaffeine] Patch for gcc6 and cmake changes
On 29 June 2016 at 00:10, Mamoru TASAKA wrote:
> Hello:
>
>
> - 元のメッセージ -----
>> 差出人: "Orcan Ogetbil"
>> 宛先: "RPM Fusion developers discussion list"
>> Cc: kaffeine-ow...@rpmfusion.org
>> 送信済み: 2016年6月29日, 水曜日 11:43:39
>> 件名: Re: [kaffeine] Patch for gcc6 and cmake changes
>>
>> On 27 June 2016 at 02:57, Leigh Scott wrote:
>> > commit ed8b668fc05a7f626d5d34e779f58be200b7884c
>> > Author: leigh123linux
>> > Date: Mon Jun 27 07:57:17 2016 +0100
>>
>> > +- char cmd[] = { 0xe0, 0x31, 0x6b, config->lnbNumber };
>> > ++ char cmd[] = { char(0xe0), 0x31, 0x6b,
>> > char(config->lnbNumber) };
>>
>> Hi, this looks like a compiler bug to me. I don't see anything
>> ambiguous in the first line. Are we sure the compilation error is the
>> intended behavior?
>>
>> Thanks,
>> Orcan
>>
>
> I guess kaffeine is C++ and converting 0xe0 (this is (int)224) to char is
> narrowing conversion, and implicit narrowing conversion on array
> initialization
> is forbidden with gcc6 (i.e. C++14), so now gcc now makes the original
> error.
>
> Regards,
> Mamoru
I see. That makes sense. But I think the problem is with
config->lnbNumber instead of 0xe0 (I didn't look into the source code,
this is my guess).
The standard [1] says (page 239):
"A narrowing conversion is an implicit conversion
(7.4)
from an integer type or unscoped enumeration type to an integer type
that cannot represent all the
values of the original type, except where the source is a constant
expression whose value after integral
promotions will fit into the target type."
Constant int 224 is within range for char as far as I know so it would
fit into char. Thus, if my interpretation is right, it should not be
considered narrowing conversion.
Thanks for guiding to the conventions of the new standard.
Cheers,
Orcan
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
Re: [kaffeine] Patch for gcc6 and cmake changes
On 27 June 2016 at 02:57, Leigh Scott wrote:
> commit ed8b668fc05a7f626d5d34e779f58be200b7884c
> Author: leigh123linux
> Date: Mon Jun 27 07:57:17 2016 +0100
> +- char cmd[] = { 0xe0, 0x31, 0x6b, config->lnbNumber };
> ++ char cmd[] = { char(0xe0), 0x31, 0x6b,
> char(config->lnbNumber) };
Hi, this looks like a compiler bug to me. I don't see anything
ambiguous in the first line. Are we sure the compilation error is the
intended behavior?
Thanks,
Orcan
Re: Change Mixxx package name
On Tue, Apr 8, 2014 at 11:55 PM, Tonet Jallo wrote: Let me see if I understood, you say i can package a mixxx without mp3 support for Fedora repo and other package mixxx-freeworld with only mp3 plugins for RPM Fusion, right? Right. But someone needs to write a patch for this, like I did for qtractor. Best, Orcan
Re: Change Mixxx package name
On Mon, Mar 31, 2014 at 9:17 AM, Tonet Jallo wrote: El 29/03/2014 17:16, Orcan Ogetbil escribió: Is it not possible to factor out the libmad code as we did for qtractor a while ago? Hello, Mixxx have a flags to exclude ffmpeg and libmad, not is necesary create a patch. Well, the qtractor patch we wrote does not just add an option to disable libmad. It builds the libmad component of qtractor into an independent shared object which is dlopened by the main program if exists on the system. This helps with packaging the libmad binding separately. Best, Orcan
Re: Change Mixxx package name
On Sat, Mar 22, 2014 at 12:52 PM, Tonet Jallo wrote: Hello, i'm packaging Mixxx without mp3 support for Fedora repos but i have a problem, i don't wanna generate a conflict with RPM Fusion repos, Mixxx are now here (with mp3 support), I think both Mixxx versions can coexist like Audacity, can you help me with that? Is it not possible to factor out the libmad code as we did for qtractor a while ago? http://cvs.rpmfusion.org/viewvc/rpms/qtractor-freeworld/devel/qtractor-libmad-factorout.patch?revision=1.1root=freeview=markup Orcan
Re: FTBFS and broken deps for F-20, free and nonfree sections
On Sun, Dec 8, 2013 at 3:21 PM, Nicolas Chauvet wrote: 2013/12/8 Sérgio Basto ser...@serjux.com Hi, I excluded ufoai, foo2hbpl2 and most kmods in this check (in my vm ) . repoquery --disablerepo=fedora,updates,updates-testing -a --pkgnarrow=available --envr | grep -vP VirtualBox|ufoai|kmod|nvidia| i686|catalyst|broadcom-wl|ndiswrapper|openafs|foo2hbpl2 | perl -pe 's/^ \d+://' | perl -pe 's/-\d.*?-\d+(\..*)?\.fc\d+(\..*)?$//' pdflib-lite-perl terminatorX Did these fail or not? Rebuilt xmms2-avcodec This one has failed: http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/19173-xmms2-freeworld-0.8-10.fc20/x86_64/build.log Anyone want to fix ? Nicolas (kwizart) I used to maintain xmms2. I can take a look. The error seems error: 'AVCODEC_MAX_AUDIO_FRAME_SIZE' undeclared Looks like an ffmpeg change. Is there some documentation for this? Orcan
Re: FTBFS and broken deps for F-20, free and nonfree sections
On Sun, Dec 8, 2013 at 8:46 PM, Sérgio Basto wrote: On Dom, 2013-12-08 at 20:14 -0500, Orcan Ogetbil wrote: error: 'AVCODEC_MAX_AUDIO_FRAME_SIZE' undeclared Looks like an ffmpeg change. Is there some documentation for this? Goggling around best answer for me is : http://opensuse-community.org/ffmpeg_port#error:_.27AVCODEC_MAX_AUDIO_FRAME_SIZE.27_was_not_declared_in_this_scope Right, but we probably need to wrap this up with some #if FFMPEG_VERSION condition. I could not find (I didn't dig through a lot though) the revision of the relevant change. Orcan
Re: Mass rebuilt for F-19 on RPM Fusion - next week
On Tue, Mar 12, 2013 at 1:15 PM, Sérgio Basto wrote: On Ter, 2013-03-05 at 22:00 +0100, Nicolas Chauvet wrote: Build failing were from jobs 16386 to 16390 as seen in: http://buildsys.rpmfusion.org/build-status/failed.psp better late then never , the fails are: 16371 terminatorX terminatorX-3_84-3_fc19 [cut] I am fixing the above failure. It seems that zlib had a recent API change. Strange for a mature library. Thanks, Orcan
Re: Mass rebuilt for F-19 on RPM Fusion - next week
On Sun, Mar 24, 2013 at 4:12 PM, Orcan Ogetbil wrote: On Tue, Mar 12, 2013 at 1:15 PM, Sérgio Basto wrote: On Ter, 2013-03-05 at 22:00 +0100, Nicolas Chauvet wrote: Build failing were from jobs 16386 to 16390 as seen in: http://buildsys.rpmfusion.org/build-status/failed.psp better late then never , the fails are: 16371 terminatorX terminatorX-3_84-3_fc19 [cut] I am fixing the above failure. It seems that zlib had a recent API change. Strange for a mature library. The build for F-18 went through but the F-19 build (job 16653) failed with DEBUG util.py:257: http://dl.fedoraproject.org/pub/fedora/linux/development/19/i386/os/Packages/g/glib2-devel-2.35.9-1.fc19.i686.rpm: [Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=fedora clean metadata DEBUG util.py:257: Trying other mirror. DEBUG util.py:257: Error Downloading Packages: DEBUG util.py:257:glib2-devel-2.35.9-1.fc19.i686: failure: Packages/g/glib2-devel-2.35.9-1.fc19.i686.rpm from fedora: [Errno 256] No more mirrors to try. I guess this is a build system issue. Should I make another build for devel? Best, Orcan
Re: Mass rebuilt for F-19 on RPM Fusion - next week
On Sun, Mar 24, 2013 at 5:40 PM, Hans de Goede wrote: On 03/24/2013 10:25 PM, Orcan Ogetbil wrote: Packages/g/glib2-devel-2.35.9-1.fc19.i686.rpm from fedora: [Errno 256] No more mirrors to try. I guess this is a build system issue. Should I make another build for devel? This sort of thing often happens when the mirrors are syncing due to a recent push of new packages. Waiting a couple of ours and then trying again usually fixes it. Sure, I'll try again later. When you try again please use plague-client requeue on the failed task, this keeps the: http://buildsys.rpmfusion.org/build-status/failed.psp List short and usable as a source to find things which need fixing. The cmdline for requeuing tasks is: PLAGUE_CLIENT_CONFIG=$HOME/.plague-client-rpmfusion.cfg plague-client requeue nr Thanks for the reminder Hans, either you or knurd once taught me this trick and I have saved it for future use. :) Best, Orcan
Re: Qtractor alternatives revisited
On Sun, Jun 24, 2012 at 3:58 AM, Brendan Jones wrote:
On 06/24/2012 05:30 AM, Orcan Ogetbil wrote:
On Sun, Jun 10, 2012 at 2:22 PM, Brendan Jones wrote:
Hi all
I'm returning to implementing alternatives rather than providing an
upstream
patch at this stage.
There is only one binary in this package. The only other files are an
icon,
desktop file and a Qt translation. Is it permissible to package only this
binary in RPMFusion and have it require the Fedora package?
I can provide a launcher script in /usr/bin which does
`readlink %{_bindir}/qtractor` so that the desktop file in the Fedora
package will work for both. The Qtractor About dialog states explicitly
whether MP3 support is disabled or not, so its easy enough to determine
which had been launched by the desktop file.
Or should I provide alternative icons, desktop file and translations for
both?
Hang on there. I managed to factor out the libmad parts of the code
into an external .so file, and use dlopen the access libmad
functionality. Things work here on my local machine. Now all I have to
do is clean up the code and (re)fresh my qmake skills to automate the
compilation, linking etc. I'll send you my patch once I am done.
Best,
Orcan
Great news Orcan, I was just about to submit my RPMFusion spec but will now
wait.
Please try out the patch [1]. I admit that I am not the mightiest
autotools wizard. Moreover, the build system made me notice that
autotools combined with qmake converges asymptotically to autoinferno
(tm).
Nevertheless this is a pretty decent start. Rui could certainly
improve the mechanism to make things fit better into his framework. A
few important points:
- The patch is against qtractor-0.5.5, that is the latest stable
version for the time being.
- Both the Fedora package and the freeworld package will need this patch.
- One needs to run autoreconf before %configure.
- In the freeworld package, you can just do a make mad_plugin
instead of full scale make to save some compilation time and build
dependencies.
Please let me know if eats your kittens, I'll send you a rebate.
Cheers,
Orcan
[1] http://oget.fedorapeople.org/review/qtractor-libmad-factorout.patch
Re: Qtractor alternatives revisited
On Sun, Jun 10, 2012 at 2:22 PM, Brendan Jones wrote:
Hi all
I'm returning to implementing alternatives rather than providing an upstream
patch at this stage.
There is only one binary in this package. The only other files are an icon,
desktop file and a Qt translation. Is it permissible to package only this
binary in RPMFusion and have it require the Fedora package?
I can provide a launcher script in /usr/bin which does
`readlink %{_bindir}/qtractor` so that the desktop file in the Fedora
package will work for both. The Qtractor About dialog states explicitly
whether MP3 support is disabled or not, so its easy enough to determine
which had been launched by the desktop file.
Or should I provide alternative icons, desktop file and translations for
both?
Hang on there. I managed to factor out the libmad parts of the code
into an external .so file, and use dlopen the access libmad
functionality. Things work here on my local machine. Now all I have to
do is clean up the code and (re)fresh my qmake skills to automate the
compilation, linking etc. I'll send you my patch once I am done.
Best,
Orcan
Re: qtractor moved to Fedora
On Mon, May 21, 2012 at 3:50 AM, Nicolas Chauvet wrote: Le 20 mai 2012 23:24, Kevin Kofler a écrit : Nicolas Chauvet wrote: But in this case I wonder why not to simply override the no replacement policy ? At least a good reason would need to be provided for still obeying this policy. Users in countries which obey software patents might not want their patent- compliant package silently replaced by a patent-encumbered one. It doens't hold, RPM Fusion free is fully made of patent encumbered components by design. Which make me wonder if we really need to requires the rpmfusion-free-release from the rpmfusion-nonfree-release from patent point of view. My point is that people using mp3 enabled qtractor from current RPM Fusion shouldn't received a disabled package either. I agree that this is a very compelling argument for most packages in RPMFusion. Many packages we have in RPMFusion focus on decoding/encoding patent encumbered media, mostly functioning towards player use cases. Nevertheless most users are listeners/viewers, rather than producers. Qtractor, on the other hand, aims to be a audio creation application for semi-professional/professional use. MP3 support is not critical for good quality audio production since you usually want to to work with lossless audio in realtime, e.g. with WAV files. (As an analogy, consider folks working as a visual effects artists for motion pictures. They certainly don't work with reduced quality compressed video.) Therefore, as the original qtractor maintainer, I did not mind Brendan to take over the package in Fedora. I suppose, having qtractor in Fedora will inflate its user base mostly thanks to the new Audio spin. Thanks, Orcan
Re: qtractor moved to Fedora
On Thu, May 17, 2012 at 2:18 PM, Hans de Goede wrote: Hi, On 05/17/2012 06:13 PM, Nicolas Chauvet wrote: 2012/5/16 Orcan Ogetbiloget.fed...@gmail.com: qtractor is now in Fedora, of course without the libmad support. Brendan Jones prepared a libmad-freeworld package with the libmad support. This package is analogous to audacity-freeworld as it conflicts with the Fedora counterpart since the libmad support is not modular. Do we have a standard procedure here at RPMFusion for X to X-freeworld renames? Do we need to file a new review request? In any case we need to remove the qtractor package from RPMFusion repos on F-17 and later. From the technical perspective, that rename can be done. (all branches). But I would like to avoid using a Conflict here. I don't remember the audacity case, but for a single binary, it would would be better to use alternatives with a higher weight for the freeworld version. Now I really wonder why is that much interesting to complicate the work that much ? Why bother and what to say when users of the mutilated fedora's qtractor will complain when cannot import mp3 ? The -freeworld was previously reserved for a complementary package of an existing fedora version. But in this case I wonder why not to simply override the no replacement policy ? At least a good reason would need to be provided for still obeying this policy. Hmm, so you're suggesting to simply have an identical named package in both repos and have the one with the higher EVR win? That is just asking for trouble. I think (if you're right about there being just one binary) that you're alternatives plan is quite good actually. I'm a strong -1 to having packages in rpmfusion which flat out replace Fedora packages. Ideally we also would not have any conflicting packages either, so a +1 to the alternatives approach. Although technically not a bad solution, as Nicolas says, setting up alternatives is too much work with too little gain. Why would anyone, with having RPMFusion enabled, want to have both of the qtractors installed and possibly switch to the Fedora version? Practically, alternatives does not add much value. My original plan was to pass over qtractor to some other maintainer from RPMFusion this summer, so I am afraid I don't really want to work on the alternatives. This leaves the decision up to Brendan, I guess. Cheers, Orcan
Re: qtractor moved to Fedora
On Wed, May 16, 2012 at 5:43 AM, Brendan Jones wrote: On 05/16/2012 06:47 AM, Orcan Ogetbil wrote: qtractor is now in Fedora, of course without the libmad support. Brendan Jones prepared a libmad-freeworld package with the libmad I think you meant qtractor-freeworld Yes, of course. Thanks for the clarification. Orcan
qtractor moved to Fedora
qtractor is now in Fedora, of course without the libmad support. Brendan Jones prepared a libmad-freeworld package with the libmad support. This package is analogous to audacity-freeworld as it conflicts with the Fedora counterpart since the libmad support is not modular. Do we have a standard procedure here at RPMFusion for X to X-freeworld renames? Do we need to file a new review request? In any case we need to remove the qtractor package from RPMFusion repos on F-17 and later. Thanks, Orcan
Re: Preparing an update for FFMpeg/x264 in Rawhide today
On Wed, Jan 25, 2012 at 6:37 AM, Nicolas Chauvet wrote: Hi, Along with an update of vlc-2.0-rc1, I would like to make an FFmpeg to current 0.9.1 version and renew x264. While you are there, could you enable the jack support in ffmpeg? I get the following when I try the example taken directly from the ffmpeg.1 manual page: $ ffmpeg -f jack -i ffmpeg -y out.wav ... Unknown input format: 'jack' Thank you, Orcan
Re: End of life for rtxxx0 kmods
On Sun, Oct 9, 2011 at 7:11 AM, Nicolas Chauvet wrote: 2011/10/8 Orcan Ogetbil: Hello RpmFusion, I wanted to make an announcement that I am dropping my maintainership for the packages: rt2860 rt2870 rt3070 kmod-rt2860 kmod-rt2870 kmod-rt3070 These were my first packages ever in the Fedora/RPMFusion world, so it is a sad departure. However I believe that the time has come. Currently the stock kernel modules fully support the devices covered by the above kmods, so I don't think there is a reason to keep them. Please remove them from the development tree(s). Can you mark them as dead.package like I did for kino for example. I will remove them from the next development push. Sure. Done (I think). Best, Orcan
End of life for rtxxx0 kmods
Hello RpmFusion, I wanted to make an announcement that I am dropping my maintainership for the packages: rt2860 rt2870 rt3070 kmod-rt2860 kmod-rt2870 kmod-rt3070 These were my first packages ever in the Fedora/RPMFusion world, so it is a sad departure. However I believe that the time has come. Currently the stock kernel modules fully support the devices covered by the above kmods, so I don't think there is a reason to keep them. Please remove them from the development tree(s). Thanks, Orcan
Re: FFmpeg Update to 0.8 in F-16/branched on Monday 26th
On Thu, Sep 29, 2011 at 3:07 PM, Nicolas Chauvet wrote: xmms2-freeworld http://buildsys.rpmfusion.org/build-status/job.psp?uid=10292 https://bugzilla.rpmfusion.org/show_bug.cgi?id=1963 I rebuilt the above with the patch Rathann provided. Thanks, Orcan
Re: Heads up: Nicolas aka kwizart is the one that handles pushing now and I'm kind of gone
On Tue, Jun 21, 2011 at 3:26 AM, Thorsten Leemhuis wrote:
Hi!
Just FYI, way later than planed I finally handed over the pushing
responsibilities to Nicolas aka kwizart a few days ago.
As announced earlier(¹), the one and only thing I feel responsible for
in RPM Fusion from now on is staging-kmod{,-addons} (I orphaned all the
other packages I owned and won't do any further kmod rebuilds for new
kernels). In case you in the Future need help specifically from me
you'll find me over the usual ways, but I might not watch this list as
closely as I did in the past.
Good luck with RPM Fusion. I hope it gets better with me finally out of
the way.
Hi Thorsten, I remember the time I got dragged by you into this chaos
to become the first RPMFusion packager without being a Fedora
packager. Well, it didn't happen this way precisely, but who cares. I
always admired your patience when someone (me) messed things up. I
know things didn't evolve the way you hoped. Well, that's life.
Thank you for everything you have done, and I hope you keep supporting
free software.
Auf Wiedersehen,
Orcan
Re: avidemux for devel/F-15: Is there a C programmer in the house?
On Sun, Apr 17, 2011 at 8:52 AM, Richard Shaw wrote: On Sun, Apr 17, 2011 at 12:53 AM, Kevin Kofler wrote: The error here is that: bool ADM_QconfigMenu::selectConfiguration(QString *selectFile, ConfigMenuType configurationType) takes a QString *. It should really be taking a const QString . Change QString *selectFile to const QString selectFile in that function's prototype and remove the from the 3 calls to that function. I think I did it right but I ran into another error. Here's the lines as changed: 141: bool ADM_QconfigMenu::selectConfiguration(const QString selectFile, ConfigMenuType configurationType) 213: selectConfiguration(QFileInfo(configFileName).completeBaseName(), CONFIG_MENU_USER); 319: configMenu-selectConfiguration(QString(configName), *configType); 359: configMenu-selectConfiguration(QString(configName), *configType); Did I make the changes correctly? I'll paste the new errors at the bottom. That function also compares the result of QComboBox::itemText, which is a QString, with selectFile. I have no idea how that works. If you change the type of selectFile to const QString , it should do the right thing. I somewhat understanding what you're saying but I'm not up on C enough to quite apply your suggested changes to the code. Thanks, Richard /builddir/build/BUILD/avidemux_2.5.4/avidemux/ADM_UIs/ADM_QT4/src/T_configMenu.cpp:141:7: error: prototype for 'bool ADM_Qt4Factory::ADM_QconfigMenu::selectConfiguration(const QString, ConfigMenuType)' does not match any in class 'ADM_Qt4Factory::ADM_QconfigMenu' This is C++ rather than C. You also need to update the corresponding header file, possibly T_configMenu.h Look for class ADM_QconfigMenu in the header file. It will contain the member prototypes. You need to update the function selectConfiguration() the same way you updated it in the implementation file T_configMenu.cpp . Orcan
Re: Lightspark
On Sat, Jan 8, 2011 at 12:42 AM, gatlin sullivan wrote: Why is Lightspark not able to be in the Fedora's official repositories? Wrong mailing list. You might want to ask this in Fedora-Legal. Orcan
Re: Handbrake possible new package
On Wed, Dec 29, 2010 at 7:33 PM, gatlin sullivan wrote: Handbrake (http://handbrake.fr/) is a utility to process and encode video (and audio). It is supported for the new version of Gnome. It actively develops for the GNU/Linux platform. A semi-nightly rpm release is made (https://build.handbrake.fr/). There is a spec file listed in its source code (http://trac.handbrake.fr/browser/trunk/gtk/ghb.spec). All of the source can be found on its web-site (http://trac.handbrake.fr/browser). Detailed build instruction (though slightly outdated) can be found documenting building, specifically on GNU/Linux, for Fedora and Ubuntu (http://trac.handbrake.fr/browser/trunk/doc/BUILD-Linux). It is licensed as GNU GPL version 2 (http://trac.handbrake.fr/browser/trunk/COPYING). If I attempt to package this after its 9.5 release - which should be relatively soon and imminent - will it meet the requirements of Rpmfusion. I do know that since it depends on certain things that are unpackageable for Fedora's repositories that it will not be acceptable there. I, with rpmfusion repositories installed plus libdvdcss, am able to install the semi-nightly builds and use them. Thus, I believe that all of the license inappropriate dependencies for Fedora must have been met by Rpmfusion. I believe that packaging this and putting into Rpmfusion would be a great addition to Fedora. I believe that most Fedora desktop users use Rpmfusion, so this as an addition to Rpmfusion will really expand the presence of Handbrake for Fedora user's to acquaint themselves. It was once proposed in RPMFusion. But we gave up. As far as I remember upstream wasn't very cooperative. (Was it them who were calling people names?) https://bugzilla.rpmfusion.org/show_bug.cgi?id=679 Orcan
Re: Requesting a howto a kmod / akmod
On Sun, Sep 19, 2010 at 4:39 AM, Eli Wapniarski wrote:
On Wednesday 01 September 2010 09:19:32 Orcan Ogetbil wrote:
On Wed, Sep 1, 2010 at 1:54 AM, Eli Wapniarski wrote:
Hi
I was just wondering if anyone knows of where I can find descent docs on
howto build an kmod / akmod.
Realtek provides drivers for the wifi 8129se but I need to rebuild the
driver everytime my kernel is updated.
Any advise on how to build a kmod / akmod be greatly appreciated.
There is a page in wiki that I once used to build my first package
(rt2870-kmod) for RPMFusion:
http://rpmfusion.org/Packaging/KernelModules/Kmods2
It should be pretty informative. Also, check the existing kmod
packages for examples.
Orcan
Trying to create the kmods. I ran into a couple of problems
1) I had to modify the line from (--repo %{repo}):
kmodtool --target %{_target_cpu} --repo %{repo} --kmodname %{name}
%{?buildforkernels:--%{buildforkernels}} %{?kernels:--for-kernels
%{?kernels}} 2/dev/null
to:
kmodtool --target %{_target_cpu} --repo rpmfusion --kmodname %{name}
%{?buildforkernels:--%{buildforkernels}} %{?kernels:--for-kernels
%{?kernels}} 2/dev/null
2) It would seem that the driver was compiled, but then it would not make
install If I were to do this manually, of course make install works
+ rm -rf
/home/eli/rpmbuild/BUILDROOT/rlt8129se-kmod-2.6.0017.0525.2010-1.fc13.1.x86_64
+ for kernel_version in
2.6.34.6-54.fc13.x86_64___/usr/src/kernels/2.6.34.6-54.fc13.x86_64
+ make install
DESTDIR=/home/eli/rpmbuild/BUILDROOT/rlt8129se-kmod-2.6.0017.0525.2010-1.fc13.1.x86_64
KMODPATH=/lib/modules//2.6.34.6-54.fc13.x86_64//extra/rlt8129se/
make: *** No rule to make target `install'. Stop.
error: Bad exit status from /var/tmp/rpm-tmp.PYAMQs (%install)
Thanks for any insight
The guidelines are like recipes. If you don't have the right
ingredient you need to come up with a replacement. Not all Makefiles
are written the same. You may need to tweak your lines a little until
things work. It is hard to say what you need to do without looking at
your specfile. Do you have an SRPM uploaded somewhere?
Orcan
Re: orphaning 3 packages
The 3 packages snowballz avbin pyglet were not claimed by any maintainers in the past 7 days. Thus I marked them dead.package in the devel branch of CVS. Please add them to the block list so that they don't end up in the next devel branch compose. Thanks, Orcan
Re: orphaning 3 packages
On Thu, Aug 5, 2010 at 7:32 AM, Paul Johnson wrote: Hi, snowballz: started as an interesting game project but upstream left it unfinished. In that case, would it not be better to withdraw the package? Sorry, what do you mean by that? Withdraw from where? Orcan
Re: orphaning 3 packages
On Thu, Aug 5, 2010 at 10:22 AM, Paul Johnson wrote: Hi, It is already not in Fedora. Do you mean RPMFusion? Oops, yep. I don't know if we have a procedure of pulling packages from stable releases. This software was packaged with the hope that it will attract some more developers. The game is still playable. It won't do harm to leave it in the old repos. Orcan
Re: RPM Fusion (Fedora - free) Package Build Report 2010-05-31
On Mon, May 31, 2010 at 3:24 PM, rpmfusion-pkgs-rep...@rpmfusion.org wrote: Changes in RPM Fusion (Fedora - free) testing/13: rt2870-2.1.2.0-2.fc13.1 --- * Fri Dec 04 2009 Orcan Ogetbil oget [DOT] fedora [AT] gmail [DOT] com - 2.1.2.0-2.1 - Blacklist kernel's rt2800usb module rt3070-2.1.1.0-3.fc13.1 --- * Fri Dec 04 2009 Orcan Ogetbil oget [DOT] fedora [AT] gmail [DOT] com - 2.1.1.0-3.1 - Blacklist kernel's rt2800usb module Can we get these pushed to stable ASAP? The same packages have been tested and are in use on F-12 since December. Otherwise the wireless will be broken for F-13 rt2870/rt3070 users who don't know about blacklisting kernel modules. I forgot to submit these to F-13 in time. Thanks, Orcan
Re: RPM Fusion (Fedora - free) Package Build Report 2010-05-31
On Mon, May 31, 2010 at 4:08 PM, Nicolas Chauvet wrote: 2010/5/31 Thorsten Leemhuis : (second try, sorry, well know keyboard error that happens now and then on this machine) On 31.05.2010 21:47, Orcan Ogetbil wrote: On Mon, May 31, 2010 at 3:24 PM, rpmfusion-pkgs-rep...@rpmfusion.org wrote: Changes in RPM Fusion (Fedora - free) testing/13: rt2870-2.1.2.0-2.fc13.1 --- * Fri Dec 04 2009 Orcan Ogetbil oget [DOT] fedora [AT] gmail [DOT] com - 2.1.2.0-2.1 - Blacklist kernel's rt2800usb module rt3070-2.1.1.0-3.fc13.1 --- * Fri Dec 04 2009 Orcan Ogetbil oget [DOT] fedora [AT] gmail [DOT] com - 2.1.1.0-3.1 - Blacklist kernel's rt2800usb module Can we get these pushed to stable ASAP? The same packages have been tested and are in use on F-12 since December. Otherwise the wireless will be broken for F-13 rt2870/rt3070 users who don't know about blacklisting kernel modules. I forgot to submit these to F-13 in time. Push in progress, even if I tend to think that it might be wise to have even updates like this out for testing for 1 or 2 days. even more better, to have someone else to test. but this could be awaited longer then... Someone else already tested this little change: https://bugzilla.rpmfusion.org/show_bug.cgi?id=1249#c0 Normally, I have nothing against leaving packages in testing for 2 weeks. However this is a noarch package, it contains no code, and the only change is the blacklist file, which has been in use in F-12 for a while now. I didn't want people to have broken wireless with F-13. Waiting 1-2 days should be fine. But I guess it is already done. Sorry, it was my fault not to push this update in time. Orcan
ACL error on committing dvdrip
Hi, I tried to update dvdrip to the new version but I got Access denied: oget is not in ACL for rpms/dvdrip/devel cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! Similar error on F-13. I should be on the ACL of this package https://bugzilla.rpmfusion.org/show_bug.cgi?id=126#c21 , and according to its changelog I did commit in the past. Moreover, I think I have provenpackager access, who don't need to be on ACL to commit. Something is fishy. Orcan
Re: Why are akmod packages arch specific?
On Sat, Apr 24, 2010 at 3:56 PM, Stewart Adam wrote: On 2010/04/24 8:16 AM, Thorsten Leemhuis wrote: But here is another thought I wanted to bring up for discussion months ago: I think it might be easier to build the akmod packages from a separate source package. That way we avoid the flipping the %define buildforkernels newest macro when updating the package, which quickly is forgotten, confuses people (afaics), and makes things harder for the one that is pushing the packages and cleaning up old kmod packages in the repos. The downsides: When updating the kmod (e.g. to a newer version or when integrating a new patch) the maintainer would have to copy the foo-kmod.spec file and all the sources to a different directory and flip a bit (the name or a macro). That's a bit more work for the packager, but more natural and hence might be easier for everyone. Opinions? +1. I think this is more intuitive and copying the spec if not a big deal anyways - just 'cvs diff -u' then 'patch /path/to/diff' wherever needed. +1 from me too. This sounds like the most unambiguous solution. It will probably require some changes in kmodtool and a rewrite of the guidelines though. Orcan
Why are akmod packages arch specific?
Is there any particular reason? Can we make them noarch? Orcan
Re: rpmfusion and no frozen rawhide
On Thu, Feb 18, 2010 at 5:47 PM, Thorsten Leemhuis wrote: On 17.02.2010 09:36, Hans de Goede wrote: So how are we going to handle the new no frozen rawhide ? That's a very interesting question -- especially as our development branch still builds against rawhide which sine a few hours is heading towards F-14. IOW: something should happen soon... I see 2 options: [...] 2) Do early branching, just like Fedora does. We could make it a bit easier on ourselves by immediately putting the new F-## repo next to the already released repo's instead of putting it under development like Fedora does. Just my 2 cent: In an ideal world we IMHO wouldn't do anything different from Fedora to avoid any confusion -- even if it's feels like we are doing something that looks better or easier... Just out of my personal curiosity. What is the current situation. plan? Fedora is next to nothing on desktop computers, without rpmfusion. Orcan
Off to vacation
Dear list, I will be away between Dec 25- Jan 18. While I expect to be able to get online occasionally during this period, I may not have the time and equipment to fix bugs. Therefore, in case something goes seriously wrong, I give permission and appreciation to everyone who is capable, to fix stuff on my packages. Thanks, Orcan PS: Yes I put my info on the vacation page on Fedora wiki.
Re: 403 - Forbidden on rpmfusion-nonfree-updates-testing
On Thu, Nov 26, 2009 at 12:40 PM, Thorsten Leemhuis wrote: Nicolas Chauvet wrote on 26.11.2009 18:12: http://download1.rpmfusion.org/nonfree/fedora/updates/testing/11/x86_64/repodata/repomd.xml cannot be acceded so mirrors arent't expected to rsync. Xavier did some changes in the past 24 hours, guess that's a unwanted side effect :-/ I worked around that my adjusting the perms with chmod manually for now. Xavier, can you make sure it doesn't happen again with the next push? tia! CU knurd This job failed too http://buildsys.rpmfusion.org/build-status/job.psp?uid=5742 with Executing command: /usr/bin/yum --installroot /var/lib/mock/fedora-11-i386-rpmfusion_free-722f75db461a49e99092ec0974ef288a0bbc8328/root/ groupinstall buildsys-build http://ftp-stud.fht-esslingen.de/pub/Mirrors/rpmfusion.org/free/fedora/updates/testing/11/i386/repodata/repomd.xml: [Errno 14] HTTP Error 403: Forbidden Trying other mirror. It looks like the mirror hasn't synced yet although it has been 2 days. But is it expected that the buildsys looks for packages from the testing repo? This is different than Fedora behavior. Orcan
Re: 403 - Forbidden on rpmfusion-nonfree-updates-testing
On Sat, Nov 28, 2009 at 4:53 PM, Adrian Reber wrote: On Sat, Nov 28, 2009 at 03:36:40PM -0500, Orcan Ogetbil wrote: On Thu, Nov 26, 2009 at 12:40 PM, Thorsten Leemhuis wrote: Nicolas Chauvet wrote on 26.11.2009 18:12: http://download1.rpmfusion.org/nonfree/fedora/updates/testing/11/x86_64/repodata/repomd.xml cannot be acceded so mirrors arent't expected to rsync. Xavier did some changes in the past 24 hours, guess that's a unwanted side effect :-/ I worked around that my adjusting the perms with chmod manually for now. Xavier, can you make sure it doesn't happen again with the next push? tia! CU knurd This job failed too http://buildsys.rpmfusion.org/build-status/job.psp?uid=5742 with Executing command: /usr/bin/yum --installroot /var/lib/mock/fedora-11-i386-rpmfusion_free-722f75db461a49e99092ec0974ef288a0bbc8328/root/ groupinstall buildsys-build http://ftp-stud.fht-esslingen.de/pub/Mirrors/rpmfusion.org/free/fedora/updates/testing/11/i386/repodata/repomd.xml: [Errno 14] HTTP Error 403: Forbidden Trying other mirror. It looks like the mirror hasn't synced yet although it has been 2 days. But is it expected that the buildsys looks for packages from the testing repo? This is different than Fedora behavior. The bits were flipping back and forth. I started my mirror script again and now the file is accessible. Adrian Thanks but this time the error is http://buildsys.rpmfusion.org/plague-results/fedora-11-rpmfusion_free/buildsys-build-rpmfusion/11-0.27/ppc/buildsys-build-rpmfusion-11-0.27.ppc.rpm: [Errno 14] HTTP Error 404: Not Found Trying other mirror. http://buildsys.rpmfusion.org/plague-results/fedora-11-rpmfusion_free/buildsys-build-rpmfusion/11-0.27/ppc/buildsys-build-rpmfusion-kerneldevpkgs-current-11-0.27.ppc.rpm: [Errno 14] HTTP Error 404: Not Found Trying other mirror. Error Downloading Packages: 10:buildsys-build-rpmfusion-kerneldevpkgs-current-11-0.27.ppc: failure: buildsys-build-rpmfusion/11-0.27/ppc/buildsys-build-rpmfusion-kerneldevpkgs-current-11-0.27.ppc.rpm from rpmfusion-free-needsign: (256, 'No more mirrors to try.') 10:buildsys-build-rpmfusion-11-0.27.ppc: failure: buildsys-build-rpmfusion/11-0.27/ppc/buildsys-build-rpmfusion-11-0.27.ppc.rpm from rpmfusion-free-needsign: (256, 'No more mirrors to try.') Child returncode was: 1 Something wrong in bombadil builder. Orcan
Re: 403 - Forbidden on rpmfusion-nonfree-updates-testing
On Sat, Nov 28, 2009 at 6:17 PM, Orcan Ogetbil wrote: Something wrong in bombadil builder. It looks like it's fixed. Thanks to whoever did that. Orcan
Re: NVIDIA / nouveau thread branch [was Re: Fedora 12 QA retrospective - feedback needed]
I have an issue with the nvidia driver in KDE. Certain actions, such as - clicking on the K-menu - clicking on the clock - using an auto hiding panel - ... freezes KDE for 10 exact seconds. Afterwards things continue as if nothing happened. I also saw this reported in nvnews.net under the evdev thread. I didn't have time to locate the source of problem, although it's most possibly evdev. Please let me know if there is a solution or workaround. kmod-nvidia-2.6.31.5-127.fc12.x86_64-190.42-1.fc12.4.x86_64 I have such error messages in Xorg.0.log: (**) Option xkb_rules evdev (**) Option xkb_model evdev (**) Option xkb_layout us [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/X (xorg_backtrace+0x28) [0x49e8d8] 1: /usr/bin/X (mieqEnqueue+0x1f4) [0x49e2a4] 2: /usr/bin/X (xf86PostMotionEventP+0xce) [0x478f0e] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fc55c359000+0x50bf) [0x7fc55c35e0bf] 4: /usr/bin/X (0x40+0x6be17) [0x46be17] 5: /usr/bin/X (0x40+0x116b13) [0x516b13] 6: /lib64/libpthread.so.0 (0x3d5520+0xefa0) [0x3d5520efa0] 7: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fc57cb7b000+0xa4a51) [0x7fc57cc1fa51] 8: /usr/lib64/xorg/modules/libwfb.so (wfbBlt+0x1045) [0x7fc57c746495] 9: /usr/lib64/xorg/modules/libwfb.so (wfbCopyNtoN+0x25e) [0x7fc57c74a1ee] 10: /usr/bin/X (miCopyRegion+0x28d) [0x54575d] 11: /usr/bin/X (miDoCopy+0x44a) [0x545c6a] 12: /usr/lib64/xorg/modules/libwfb.so (wfbCopyArea+0x4c) [0x7fc57c7494cc] 13: /usr/lib64/xorg/modules/libwfb.so (wfb_image_from_pict+0x302) [0x7fc57c74e8f2] 14: /usr/lib64/xorg/modules/libwfb.so (wfbComposite+0xd4) [0x7fc57c74ebd4] 15: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fc57cb7b000+0x33e817) [0x7fc57ceb9817] 16: /usr/bin/X (0x40+0xd1c80) [0x4d1c80] 17: /usr/bin/X (0x40+0x15e459) [0x55e459] 18: /usr/bin/X (0x40+0x15e725) [0x55e725] 19: /usr/bin/X (0x40+0xa2366) [0x4a2366] 20: /usr/bin/X (0x40+0x4edde) [0x44edde] 21: /usr/bin/X (MapWindow+0x179) [0x452ec9] 22: /usr/bin/X (0x40+0x2bdc6) [0x42bdc6] 23: /usr/bin/X (0x40+0x2c69c) [0x42c69c] 24: /usr/bin/X (0x40+0x21cfa) [0x421cfa] 25: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x3d5461eb1d] 26: /usr/bin/X (0x40+0x218a9) [0x4218a9]
Re: NVIDIA / nouveau thread branch [was Re: Fedora 12 QA retrospective - feedback needed]
On Wed, Nov 25, 2009 at 8:16 PM, Rahul Sundaram wrote: On 11/26/2009 06:37 AM, Orcan Ogetbil wrote: I have an issue with the nvidia driver in KDE. Certain actions, such as - clicking on the K-menu - clicking on the clock - using an auto hiding panel - ... freezes KDE for 10 exact seconds. Afterwards things continue as if nothing happened. I also saw this reported in nvnews.net under the evdev thread. I didn't have time to locate the source of problem, although it's most possibly evdev. Please let me know if there is a solution or workaround. Refer to https://fedoraproject.org/wiki/Common_F12_bugs#Problems_when_using_the_proprietary_NVIDIA_graphics_driver_.28especially_with_KDE.29 Rahul Oh great. Thank you! Orcan
Re: Review swaps
On Thu, Nov 19, 2009 at 8:00 AM, Nicolas Chauvet wrote: 2009/11/19 Hans de Goede: Hi, I've just submitted a review request for Maelstrom (a game) as it is being kicked out of Fedora due to issues with the license for its data files: https://bugzilla.rpmfusion.org/show_bug.cgi?id=952 Since this is moving from Fedora it should be an easy review, anyone want to swap a review with me ? If it was in fedora, it doesn't need to be reviwed again... Yeah. Was it reviewed before or was it in the merge review queue? Orcan
Re: HandBrake in rpmfusion? (continued from bug #69)
On Sun, Nov 15, 2009 at 7:30 PM, Justin wrote: First, relevant info: Bug report: https://bugzilla.rpmfusion.org/show_bug.cgi?id=679 IRC convo w/ HandBrake devs: http://handbrake.fr/irclogs/handbrake/handbrake20091115_pg2.html Summary (from my understanding): 1. Fedora/RPMfusion doesn't bundle libraries with programs. 2. HandBrake uses customized versions of a lot of libraries, which they bundle. 3.In trying to get it packaged Bernard Johnson (0x100 in the IRC convo) was trying to reach a compromise where he used system libraries where possible, leaving bundled libs only where necessary. 4. HandBrake devs either wants all bundled libraries included or for it to not be in the distros repo. Current choices are: 1. Package it with all bundled libs (against policy) 2. Package it the way we want because we can 3. Don't package it My 2c: HandBrake is popular, so seeing it in the repos is a good thing (tm). HandBrake devs are being unreasonable and, honestly, downright rude and aggressive. So, whether that ends up being option one or two, we should do it the way we think is best and they can deal. If we're feeling extra nice we could add a note about it being unofficial and unsupported by the HandBrake team, maybe even with a pointer to their version. I vote for 3. Considering their attitude, it's not worth. Let them distribute their broken stuff themselves, unless if someone in rpmfusion has the stomach to handle the issues. I never heard handbrake before the review request and I doubt that I ever will. Orcan
Re: Question about licensing of kmods
On Thu, Nov 5, 2009 at 1:55 PM, Till Maas wrote: On Tue, Nov 03, 2009 at 11:51:15PM +0100, Kevin Kofler wrote: Till Maas wrote: If this is a problem, then it cannot go into any RPMFusion repository, because packages in RPMFusion still need to be legally distributable, even if they are in the nonfree repository. All GPL-incompatible kmods are illegal, yet RPM Fusion still ships them. So, as kmod-nvidia and others are allowed, I don't see why this one wouldn't be allowed as well. Is it an official RPMFusion opinion, that these kmods are illegal? Because then these FAQ entry needs to be adjusted: http://rpmfusion.org/FAQ#head-3c87307eb360d4f17920dcf064039366de8f58df No it is only personal opinion. There is an ongoing debate about this and this is certainly a grey area. It depends on how a particular country's copyright law defines the concept derived work. If the country considers closed source kernel modules as derivatives of the Linux kernel, then yes, it is a violation of GPL. However many, including Linus, think that it is hard to consider these drivers as derivative work. Since there is no court case example ruling in either way, we can't really be 100% sure, either way. For instance, NVidia is a big company. We are sure that they got some legal advise before releasing binary drivers. Orcan
Re: Question about licensing of kmods
On Tue, Nov 3, 2009 at 1:00 PM, Jochen Schmitt wrote: Hallo, I'm reviewing the package openafs-kmod new. The releated review request you may find at: https://bugzilla.rpmfusion.org/show_bug.cgi?id=803 Unfortunately, The webpage https://fedoraproject.org/wiki/Licensing shows, that the IBM Public License is not compatible to the GPLv2 license which is the license used for the Linux kernel. So I want to ask, to which repository - free or non-free - we should take this package. As far as I know, GPL has an exception for linking against system components (i.e. kernel). So free repo should be fine. Please correct me if I'm wrong. Orcan
Re: Rawhide frozen in rpmfusion.
On Wed, Oct 21, 2009 at 2:41 AM, Nicolas Chauvet wrote: 2009/10/21 Thorsten Leemhuis : ... What about all the rebuilds against the new ffmpeg? Shall I just bump and queue all the packages depending on it to see what breaks? Yes, packages that weren't already updated need a rebuild. I guess we need a mass rebuild for the package that weren't rebuild recently anyway. Is there gonna be a mass rebuild for F-12? I guess so because of the i586-i686 change. Please let me know when you folks are planning to do this. I need to update the desktop files of certain multimedia applications to comply with the FedoraStudio feature of Fedora 12, which I announced here a couple weeks ago. Orcan
Re: Mass rebuild? (was: Re: Rawhide frozen in rpmfusion.)
On Wed, Oct 21, 2009 at 3:13 AM, Thorsten Leemhuis wrote: Orcan Ogetbil wrote on 21.10.2009 08:46: Please let me know when you folks are planning to do this. I need to update the desktop files of certain multimedia applications to comply with the FedoraStudio feature of Fedora 12, which I announced here a couple weeks ago. As I said: there IMHO is not much time anymore for big changes and a mass rebuild... F-12 release is 4 weeks from now. I don't think it's too late for a mass rebuild. That said, since I have never done a mass rebuild myself, this is nothing but a guess. I don't want to speak for people who would do the actual work. I will finish the FedoraStudio work before the end of this Sunday. It's nothing big. I just need to add categories to some desktop files. But I would like to know: shall I make new builds or just commit to cvs? Orcan
Re: How to move on with infrastructure?
On Wed, Oct 21, 2009 at 2:47 PM, Thorsten Leemhuis wrote: On 21.10.2009 20:39, Jochen Schmitt wrote: Am 21.10.2009 20:27, schrieb Thorsten Leemhuis: Some of you might be aware of it, other not, but we afaics have a (whole) lot of medium-sized and small problems in the infrastructure area(¹). The main ones from the top of my head: - multiple people offered to help in the past (²), but not even one of those people found its way into the project/the infrastructure team: Why? It can't continue like that, as that is a route to fail... - it sometimes take a lot of time until cvs requests are done I have offer my help Many thanks for that! and ask for documentation how it's works. Lack of documentation on how our infra and the team that takes care of it is one of the problems I forgot to mention... Sorry. But unfortunately I haven't got any response. I could give you access in some areas, but I also only partly know how things work. And for now I would prefer not to hand out access to not mix things up even more and to not get into Xaviers way. If the lack of documentation is one of the problems, can we arrange a time to make a workshop/lecture on IRC, so that people who have the knowledge could deliver it? I assume that there are various folks who could offer help, even at a minimal level. But it is not easy to figure out where to get a lead. Orcan
The .desktop files of multimedia packages
Hi all, As some of you might have noticed, I updated some of your multimedia packages in Fedora, so that they have proper Categories that will populate our multimedia/soundvideo menu's submenus. The submenus will be enabled if you install the multimedia-menus package that is currently available in rawhide and F-11 testing. This was announced in fedora-devel list around August 10th. I am asking RPMFusion packagers the same thing: Please update the .desktop files according to this description [1]. Most likely we will have the F-12 branching here 1-2 weeks before the F-12 release. If the .desktop files of some packages are not updated by then, I will go through them one by one (as I did in Fedora) shortly before the F-12 branching. Please let me know if you do not your package to be touched. Also let me know if you have questions about categorization about you package. Thanks! Orcan PS: What is the approximate F-12 branching date? [1] http://fedoraproject.org/wiki/Features/FedoraStudio
Re: Approving cvsextra group with sponsor rights for s4504kr
On Wed, Sep 16, 2009 at 10:50 AM, Jochen Schmitt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, it may be nice, if anyone can approve my membership request for the cvsextras group for the FAS account s4504kr and grant me sponsor rights, because I'm a sponsor in the Fedora project. Thanks in advance. Best Regards: Jochen Schmitt I took care of this. Cheers, Orcan
lisas.de busted
http://buildsys.rpmfusion.org/build-status/job.psp?uid=4806 http://buildsys.rpmfusion.org/build-status/job.psp?uid=4809 http://buildsys.rpmfusion.org/build-status/job.psp?uid=4812 It has been failing for about a week now. I guess it just needs a simple update. Orcan
Re: avidemux 2.5 plugins - comments/ideas?
On Thu, Jul 23, 2009 at 4:29 PM, Stewart Adam wrote: Hi, Avidemux 2.5 was released recently which changed the build procedure quit a bit. Much of the functionality that was included in avidemux 2.4 has been split out into plugins which are now build separately from the main package. This introduces some problems for building, as the plugins require a installation of the main package (some shared libraries) to build properly. The two ways to package avidemux are: 1. Build main package, make install to a local directory in order to build plugins and then install everything together into $RPM_BUILD_ROOT 2. Split out the plugins into a different package and BR avidemux-libs I prefer option 2 since the plugins can be patched/updated without having to redownload the shared libraries again. However, it looks like upstream is packaging plugins in the main tarball so this point is null. Would there be any other reasons for sticking with option 2? avidemux 2.4 is very broken (it crashes when open videos and doesn't compile on ppc) so if in a few days nothing has come up I'm going to close the review for avidemux-plugins [1] and go ahead with option 1. Thanks, Stewart [1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=719 I would contact upstream and ask if they are planning to release any of the plugins separately in the future. If the plugins will always be distributed inside the main tarball, then it makes sense to proceed with option 1. Orcan
Re: 64bit flash
On Wed, Jun 24, 2009 at 1:28 AM, Justin wrote: On Wed, Jun 24, 2009 at 1:12 AM, James Cassell wrote: On Wed, 24 Jun 2009 01:06:45 -0400, Justin wrote: wondering why rpmfusion uses nspluginwrapper for flash on 64bit when there's a 64bit flash out? unless something has changed, rpmfusion doesn't distribute flash; redistribution is forbidden: http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-November/002503.html (it's quoted there; didn't have the immediate link for the original) -- James Cassell Ahh, hmm, so they don't. I'm not sure where I got the idea that I'd installed it from rpmfusion. Well, here's a question: why not have a package with a script that pulls flash from adobe? It's not that trivial. How will that package handle the updates on flash? For any solution I came up with, downloading the plugin from adobe seems equally easy if not easier. Feel free to write a script. We'll consider it. Orcan
Re: Branched for F11
On Sat, Jun 6, 2009 at 3:08 AM, Thorsten Leemhuis wrote: On 30.05.2009 15:45, Thorsten Leemhuis wrote: On 27.05.2009 22:12, Thorsten Leemhuis wrote: On 27.05.2009 20:01, Thorsten Leemhuis wrote: [...] But I'd guess nobody should build anything in the devel branch anymore over the next few days apart from critical bugfixes to make sure we don't introduce any new bugs in those repos. Hence I plan to review any package updates a bit closer before pushing them. If something odd comes up I'll ask packagers or this list for advice. kwizart build a new totally new nvidia driver (180 - 185) for devel/F11 release repos: http://buildsys.rpmfusion.org/build-status/job.psp?uid=4139 http://buildsys.rpmfusion.org/build-status/job.psp?uid=4138 It might be quite an important component, but problems with it can (seldomly) damage hardware and if something is wrong with that package it can bite users for the next 13 months. Thus I'm quite unwilling to push this to the F11 release repos at this point with F11 only three days away. A few days updates-testing for F11 IMHO is the way better place IMHO. Thus I didn't push it yet. Does someone agree/disagree with that (kwizart obviously will disagree, asking more for other opinions here)? If enough people disagree then I can still push it, but if something is wrong then it might get hard to fix (which would cost quite a bit of my time, which I don't have right now) because rawhide might move on today/tomorrow and thus would need another round of mock adjustments on all builders. CU knurd My user perspective: I've been using the 185 driver for a couple days now without any problems. It won't be a problem for me if me include 185 in the F-11 release repo. My packager perspective: I agree with you on this. The 185 package didn't get enough testing time. But can we ship the 180 driver in the F-11 release repo at least? Orcan
Re: rpms/yabause/devel .cvsignore, 1.5, 1.6 sources, 1.5, 1.6 yabause.spec, 1.7, 1.8
On Tue, Jun 2, 2009 at 1:49 PM, Julian Sikorski wrote: Author: belegdol Update of /cvs/free/rpms/yabause/devel In directory se02.es.rpmfusion.net:/tmp/cvs-serv15941 Modified Files: .cvsignore sources yabause.spec Log Message: * Tue Jun 02 2009 Julian Sikorski belegdol[at]gmail[dot]com - 0.9.10-1 - Updated to 0.9.10 - Added openal-devel to BuildRequires - Dropped unnecessary configure switches, they don't change anything Uh oh, did you read this: http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2009-May/005358.html You built the same package for both F-11 base and F-11 updates. Orcan
Re: rpms/yabause/devel .cvsignore, 1.5, 1.6 sources, 1.5, 1.6 yabause.spec, 1.7, 1.8
On Tue, Jun 2, 2009 at 1:55 PM, Orcan Ogetbil wrote: On Tue, Jun 2, 2009 at 1:49 PM, Julian Sikorski wrote: Author: belegdol Update of /cvs/free/rpms/yabause/devel In directory se02.es.rpmfusion.net:/tmp/cvs-serv15941 Modified Files: .cvsignore sources yabause.spec Log Message: * Tue Jun 02 2009 Julian Sikorski belegdol[at]gmail[dot]com - 0.9.10-1 - Updated to 0.9.10 - Added openal-devel to BuildRequires - Dropped unnecessary configure switches, they don't change anything Uh oh, did you read this: http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2009-May/005358.html You built the same package for both F-11 base and F-11 updates. Orcan Ah, this is the commit email, not the build. Sorry for the false alarm. Orcan
Re: Sponsors in RPM Fusion
On Wed, Apr 15, 2009 at 3:17 AM, Hans de Goede wrote: On 04/15/2009 07:06 AM, Thorsten Leemhuis wrote: On 02.04.2009 09:20, RPM Fusion Bugzilla wrote: http://bugzilla.rpmfusion.org/show_bug.cgi?id=478 - lkundrak, will your sponsor Justin? Yes, I can sponsor him, provided someone upgrades my rpmfusion account to sponsor. (I'm already a sponsor in Fedora) We haven't discussed how to become a RPM Fusion sponsor yet iirc, but I'd say we follow the same patter we use in other places as well: If you are a sponsor in Fedora then you can become a sponsor in RPM Fusion. I'd just say the one that wants to become sponsor for RPM Fusion once states his intention in public to make sure everybody is aware of it. Is that fine for everybody? If I get a few +1 and if nobody yell's I'd like to give lkundrak sponsor status in a few days. +1 And I would like to add, that I would even like to see some procedure for people to become rpmfusion sponsor only. We've a few people who are doing very good work, which are not Fedora sponsors (yet?) and we sure could use more rpmfusion sponsors. Regards, Hans If it is okay for everyone, I would like to nominate myself for sponsorship in rpmfusion. I did more than 90 reviews so far (Fedora+rpmfusion). I think I learned how certain things go by now. I am neither a Fedora sponsor, nor am I planning to become one. It is too hard for me to keep track of people there. Note that I am considering this to speed things up. We also have other very good and active reviewers in rpmfusion. Is there no one else interested in being a sponsor? Orcan
Re: builder status of builder.wilsonet.com
On Wed, May 20, 2009 at 2:48 PM, Jarod Wilson wrote: On 05/20/2009 12:11 PM, Mamoru Tasaka wrote: Jarod Wilson wrote, at 05/20/2009 02:55 AM +9:00: Ugh. I thought the builder was set up to handle issues like this when its local mirror went AWOL, which is exactly what happened, due to stupidity on my part last night... Mirror volume *should* be fully repopulated Real Soon Now... Lemme go check on progress... Finally rebuild succeeded, thank you. Thorsten disabled the builder while the mirror finished repopulating, but its fully repopulated now, so it should be fine to turn the builder back on. --jarod My xmms-mplayer build on builder.wilsonet.com failed three times (once in F-9, twice in F-10) with ... Total size: 11 M Total download size: 175 k http://mirror.wilsonet.com/fedora/releases/10/Everything/i386/os/Packages/libmikmod-3.2.0-3.beta2.fc9.i386.rpm: [Errno 14] HTTP Error 404: Not Found Trying other mirror. Error Downloading Packages: libmikmod-3.2.0-3.beta2.fc9.i386: failure: Packages/libmikmod-3.2.0-3.beta2.fc9.i386.rpm from fedora: [Errno 256] No more mirrors to try. Cleaning up the buildroot... /usr/bin/setarch i686 /usr/bin/mock clean --uniqueext=090b4dd3171544615c5053ea5495c5c0665bbc99 -r fedora-10-i386-rpmfusion_free ... http://buildsys.rpmfusion.org/build-status/job.psp?uid=3941 http://buildsys.rpmfusion.org/build-status/job.psp?uid=3942 http://buildsys.rpmfusion.org/build-status/job.psp?uid=3943 Orcan
Re: orphaning xmms-wma
On Thu, May 21, 2009 at 4:08 PM, Michael Schwendt wrote: On Thu, 21 May 2009 15:29:04 -0400, Orcan wrote: xmms-wma is now marked dead.package. I advise the removal of it from the F-11 (devel) repo. It can also be removed from F-9 and F-10 as the package is non-functional at least on x86_64 and no one is providing a fix. Not entirely right as I've attached two patches for it: https://bugzilla.rpmfusion.org/show_bug.cgi?id=357#c7 https://bugzilla.rpmfusion.org/show_bug.cgi?id=357#c10 Well, yes. And thanks. But still, they don't solve the problem. I still hear garbage and xmms crashes on exit. Orcan
Re: builder status of builder.wilsonet.com
On Thu, May 21, 2009 at 3:49 PM, Jarod Wilson wrote: On May 21, 2009, at 3:39 PM, Orcan Ogetbil wrote: On Wed, May 20, 2009 at 2:48 PM, Jarod Wilson wrote: On 05/20/2009 12:11 PM, Mamoru Tasaka wrote: Jarod Wilson wrote, at 05/20/2009 02:55 AM +9:00: Ugh. I thought the builder was set up to handle issues like this when its local mirror went AWOL, which is exactly what happened, due to stupidity on my part last night... Mirror volume *should* be fully repopulated Real Soon Now... Lemme go check on progress... Finally rebuild succeeded, thank you. Thorsten disabled the builder while the mirror finished repopulating, but its fully repopulated now, so it should be fine to turn the builder back on. --jarod My xmms-mplayer build on builder.wilsonet.com failed three times (once in F-9, twice in F-10) with ... Total size: 11 M Total download size: 175 k http://mirror.wilsonet.com/fedora/releases/10/Everything/i386/os/Packages/libmikmod-3.2.0-3.beta2.fc9.i386.rpm: [Errno 14] HTTP Error 404: Not Found Trying other mirror. Oh hell. I suck again. The releases subtrees are still missing. I was wondering why it seemed like a lot less space was being used on the mirror volume. I'll get that taken care of shortly. Ugh. It looks like the issue is resolved now. Thanks! Orcan
Re: ffmpeg on F-10
On Thu, May 21, 2009 at 10:36 AM, Thorsten Leemhuis wrote: On 20.05.2009 19:31, Orcan Ogetbil wrote: $ rpm -q ffmpeg ffmpeg-0.4.9-0.55.20080908.fc10.x86_64 This is a rather old version. Considering the EOL of F-10 is Jan 2010, and at that time this ffmpeg version will be 16 months old... I know that important bugfixes are being backported but still, there are still annoying ffmpeg bugs: https://bugzilla.rpmfusion.org/show_bug.cgi?id=213 https://bugzilla.rpmfusion.org/show_bug.cgi?id=359 https://bugzilla.rpmfusion.org/show_bug.cgi?id=527#c73 The first bug report above is over 5 months old. Still, no action is taken. People using F-11 report that they don't have these problems. What is the cost of updating ffmpeg on F-10? Note that Dominik once considered to update ffmpeg http://thread.gmane.org/gmane.linux.redhat.fedora.rpmfusion.devel/3195/ But he afaics got distracted. But part of the question are answered in that thread (see my reply there). In short: everything imho must me properly prepared and tested before it's committed, to make sure its a smart and painless move for everyone involved. I read it now. It looks like he changed his mind after some people mentioned about maintaining stability. However this is not the case now. There are these outstanding bugs. Moreover, I suspect that https://bugzilla.rpmfusion.org/show_bug.cgi?id=226 is suffering from an old ffmpeg bug too. I think that the upgrade deserves a reconsideration. Rathann, do you copy? Orcan
Re: RFC: drop FTBFS packages? (was: Re: Massrebuild status)
On Wed, Apr 29, 2009 at 5:27 AM, Thorsten Leemhuis wrote: (trying with a different topic) On 26.04.2009 14:13, Thorsten Leemhuis wrote: On 12.04.2009 14:43, Thorsten Leemhuis wrote: On 31.03.2009 08:01, Thorsten Leemhuis wrote: [...] Here is a list of packages that sill haven't been rebuild: 502 2009-04-07 2009-04-07 snes9x 503 2009-04-07 2009-04-07 raine 505 2009-04-07 2009-04-07 sidplay 508 2009-04-07 2009-04-07 streamri 510 2009-04-07 2009-04-07 subtitle 514 2009-04-07 2009-04-07 streamdv 516 2009-04-07 2009-04-07 flvtool2 519 2009-04-07 2009-04-11 vdr-mp3 [...] Just to point out the obvious: A few bugs are five days (19 days now) old and the maintainer didn't even replied yet. I'd wondering if we in should drop the packages from the devel repo that remain unfixed in one or two weeks from now; of course we would need to announce that in the bug report a few days before we actually do it. And we'd need to check if the packages we drop are needed by other packages in the repo. Options? Nobody? Should I take that as agreement or disagreement to let's drop what doesn't build anymore idea? +1 (to agreement) Orcan
dssi-vst: RPMFusion material?
What is VST? VST's and VSTi's are audio plugins and instruments usually written for Windows. They are professionallyand widely used in Digital Audio Workstations (DAWs), such as Cubase. In fact, they are mostly nonfree (I found some free (as in beer) VST's but I didn't encounter a free (as in freedom) VST's yet). Here is more information in case you are interested: http://en.wikipedia.org/wiki/Virtual_Studio_Technology There is a dssi plugin wrapper designed for using these Windows VST plugins in Linux. And I packaged it: https://bugzilla.redhat.com/show_bug.cgi?id=492221 In order to use dssi-vst on x86_64, it needs to be built against 32bit wine + 64bit other libraries. Now here are my questions: 1- Does our buildsys support such builds? Fedora's x86_64 buildsys does not contain wine, and I'm reluctant to submit this package just i386, because it won't be much useful with x86_64 audio software (ardour, rosegarden etc) 2- Since there are no known free VST plugins which one can use with dssi-vst, I am also not sure if this is Fedora material. What do you folks think? Cheers, Orcan
Re: Return of the King? (OSSv4)
On Mon, Apr 20, 2009 at 3:29 AM, Andrea Musuruane wrote: On Mon, Apr 20, 2009 at 5:56 AM, Orcan Ogetbil wrote: I don't remember reading a discussion about this. Is there anyone who made some research about OSSv4? I saw some good reviews and some folks in fedoraforum are asking about it. Can it be considered for RPMFusion? Practically, it replaces ALSA, or maybe it can be thought as an alternative. What's the problem of getting it in Fedora? Bye, Andrea. OSS has hardware drivers. It comes with bunch of kernel modules. Orcan
Re: Return of the King? (OSSv4)
On Mon, Apr 20, 2009 at 4:53 AM, Nicolas Chauvet wrote: 2009/4/20 Orcan Ogetbil: OSS has hardware drivers. It comes with bunch of kernel modules. That would mean backport of already present oss kernel modules or are theses OSS kernel modules was removed previously and only the compat layer was available ? I think the latter, but I'm not very sure. I was wondering if anyone here did some tests. What is the userland needs for that ? In my case (vlc), Iv'e disabled the oss support (along with v4l1) by F-11 I disabled OSS in some of my packages too. But if OSSv4 works better than ALSA for some users, it is worth considering. I guess we need to do more research. I'm not against to have some experiments done externally from rpmfusion (read: I would allow it a tobedefined rpmfusion-experimental), but not if this mean recompilation of userland applications. Nicolas (kwizart) I agree. Orcan
Return of the King? (OSSv4)
I don't remember reading a discussion about this. Is there anyone who made some research about OSSv4? I saw some good reviews and some folks in fedoraforum are asking about it. Can it be considered for RPMFusion? Practically, it replaces ALSA, or maybe it can be thought as an alternative. Orcan
Re: Kdenlive packages
On Wed, Apr 8, 2009 at 7:26 AM, Zarko Pintar wrote: Hello, My name is Zarko and I bring to RPM Fusion three packages: MLT, MLT++ and Kdenlive Links are here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=527 https://bugzilla.rpmfusion.org/show_bug.cgi?id=528 https://bugzilla.rpmfusion.org/show_bug.cgi?id=529 I am new here and I did not sponsored yet. On Fedora I put four packages last month but nobody yet sponsored me there. Why? I do not know, maybe my packages isn't important enough. So, Kdenlive and MLT Framework are on RPM Fusion Wishlist and these packages using ffmpeg libraries for coding/encoding, and without ffmpeg all of this staff are mostly useless. ffmpeg can not be added separatly (only at build time). All of these I checked with mock on i386 and x86_64 architectures... Also, I'm a member of development team at Kdenlive as bugreporter, translator and potentialy Fedora packager. Currently these packages are on my private Fedora repository for testing purposes. kind regards, Zarko Pintar Thank you for taking the step to bring these packages to RPMFusion. These packages (mlt and mlt++) have open review requests in Fedora's bugzilla but I don't think anything will come out of them. Things are going pretty slow there. Orcan
Re: bug #2 search
On Wed, Apr 8, 2009 at 7:11 PM, solarflow99 wrote: what is the proper way to get this listing again? thanks Come again? This is the bug #2 https://bugzilla.rpmfusion.org/show_bug.cgi?id=2 It is a tracker bug for new package review requests. Each new review request must block this bug. So, what do you need from this bug? Orcan
Re: orphaning xmms-wma
On Fri, Apr 3, 2009 at 3:09 PM, Thorsten Leemhuis wrote: On 02.04.2009 10:52, Orcan Ogetbil wrote: There is this long standing crasher bug [1] that I couldn't to solve after spending many hours and days. At the end, as of today, I finally lost my interest in this package. Instead, I packaged xmms-mplayer [2] which can play not only wma files, but also whatever mplayer can play (audio and video). If there's anyone who wants to fix the bug and maintain xmms-wma, (s)he can take it over. I'm pretty much done with this package. When you finally drop it please mark it as dead.package in CVS and tell me to remove it from the rawhide branches. tia! I'll do this as soon as xmms-mplayer gets approved and imported. Orcan
orphaning xmms-wma
There is this long standing crasher bug [1] that I couldn't to solve after spending many hours and days. At the end, as of today, I finally lost my interest in this package. Instead, I packaged xmms-mplayer [2] which can play not only wma files, but also whatever mplayer can play (audio and video). If there's anyone who wants to fix the bug and maintain xmms-wma, (s)he can take it over. I'm pretty much done with this package. Orcan [1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=357 [2] https://bugzilla.rpmfusion.org/show_bug.cgi?id=xmms-mplayer
Re: BRing qt3 on both fedora and EPEL
On Thu, Apr 2, 2009 at 5:19 PM, David Timms wrote: Hi, I got a few hints reqarding this on IRC: I'm trying to adjust my spec to BR qt 3, in a way that works on EPEL and Fedora. mharris suggested this might work: BuildRequires: qt-devel = 3 BuildRequires: qt-devel 4, which -bs ok, actual build fails: error: Failed build dependencies: qt-devel 4 is needed by dvbcut-0.6.0-4.svn157.fc10.src The qt packages in Fedora have Epoch: 1 . I don't know about EPEL. But you could try something like: BuildRequires: qt-devel = 1:3 BuildRequires: qt-devel 1:4 Orcan
Re: Massrebuild status
On Tue, Mar 31, 2009 at 2:01 AM, Thorsten Leemhuis wrote: Hi! The massrebuild finished here is a list of packages that failed: avbin-7-8_fc11 on http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/3187-avbin-7-8.fc11/ppc Just for the record, this one is rebuilt with EVR 7.9. It is in needsign. Orcan
Re: mass rebuild (was: Re: soname bumps: faad2-2.7 and x264)
On 27.03.2009 07:06, Thorsten Leemhuis wrote: [...] Regarding the mass rebuild: I'll queue all packages that haven't been build in rawhide since 2009023 for a rebuild over the next few days if nobody yells or does it before I get to it. I was wondering if the mass rebuild will be done over tagged versions of packages in cvs or not? The latest version of xmms-wma is currently untagged in rawhide, because it doesn't function properly and we are working on it. Rathann? Any chance of having a look at it before F-11 is released? When is the branching to F-12 going to be done? Orcan
Re: overhauled qmc2 spec file
Both sdlmame and sdlmess subpackages have the same summary and description. Is that intentional? -Orcan
Re: x264 and ffmpeg updates coming to rawhide
--- On Wed, 12/17/08, Hans de Goede wrote: Hmm, Build fails on ppc? : http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/2089-gstreamer-ffmpeg-0.10.6-1.fc11/ It claims it cannot find ffmpeg any idea why that would be ? This is an arch-independent error. The same thing happened yesterday for xmms2-freeworld build. I believe that there's a problem with ffmpeg's .pc file. The stable branches don't have this issue. Only the devel branch does. -oget
Re: Presto test repositories for rpmfusion
--- On Wed, 10/29/08, Jonathan Dieter wrote: Just a heads up that there are now presto test repositories for rpmfusion available. Install yum-presto and change your baseurl to the following: F8 i386 - free: http://lesloueizeh.com/f8/i386/rpmfusion-updates-free F8 i386 - nonfree: http://lesloueizeh.com/f8/i386/rpmfusion-updates-nonfree F9 i386 - free: http://lesloueizeh.com/f9/i386/rpmfusion-updates-free F9 i386 - nonfree: http://lesloueizeh.com/f9/i386/rpmfusion-updates-nonfree Rawhide i386 - free: http://lesloueizeh.com/devel/i386/rpmfusion-free Rawhide i386 - nonfree: http://lesloueizeh.com/devel/i386/rpmfusion-nonfree I would love to see the official rpmfusion repositories become presto-enabled, but it would take some love from those who understand the build system. So I'll keep these running until that happens. Jonathan Any updates on this? Other arch's etc? -oget
Re: Adobe Flash package (was Re: suns' java leagal issues)
--- On Wed, 11/19/08, مؤيد السعدي wrote: the more serious thing about it is this term in the FAQ Can I make the Adobe Players available directly from my website? No. The Adobe free Player distribution agreement does not allow you to distribute the Players from your website. I guess this mean that rpmfusion can't host such thing the full text of the license http://www.adobe.com/products/clients/all_dist_agreement.html the funny thing that adobe don't want to answer us Can I get clarification of the legal terms by someone at Adobe? Adobe cannot offer legal guidance on the terms of the Player Distribution Licensing Agreement; rather this is a matter between you and your attorney. Adobe offers the License Agreement as-is and enters into custom agreements on an extremely limited basis. So shall we ask Adobe for a special permission? Note that, although our chances of an approval are quite slim, asking won't hurt. And is there anyone who wants to take the lead? -oget
Re: the libdvdcss issue
--- On Tue, 11/18/08, Andreas Thienemann wrote: Hello Rex, On Tue, 18 Nov 2008, Rex Dieter wrote: [Not shipping something in order to prevent people from comitting legally questionable acts in their locale] I am swayed by that argument, but this is a special case. I'm still very concerned over issues around 1. fedora being able to refer to rpmfusion Fedora is not able to refer to ATRpms or Dag either IIRC. Yet they have quite a lot of users, right? or the more general: 2. journalists/websites cannot mention rpmfusion either or even Same as above. I don't quite understand why they can't refer to rpmfusion-free. rpmfusion-nonfree, on the other hand, is the best place for distributing such stuff (Sun's java, libdvdcss, flash (if we can get the permission) ). I see nothing wrong in putting such a gap between rpmfusion-free and rpmfusion-nonfree. libdvdcss is more of a hardware driver. Lots of people have the hardware and most of them are allowed to use this driver for their hardware where they live, so why not let them have it? I believe that we should put a disclaimer notice on the rpmfusion-nonfree-release RPM, telling the users that it is their responsibility to check the license and the legal issues by installing any package from this repo. The disclaimer notice should pop up when someone installs this repository RPM. What is the possibility of doing this or something with the same effect? -oget
Re: latest kernel's gspca-kmod missing
Ignacio Vazquez-Abrams wrote: On Mon, 2008-11-17 at 21:31 +0100, Farkas Levente wrote: the gspca-kmod missing for the latest kernel. it'd be useful for everybody who has webcam. # rpm -qpl /home/repo/remote/fedora/updates/9/i386.newkey/kernel-2.6.27.5-37.fc9.i686.rpm | grep -c '/gspca.\+\.ko' 21 That's probably why it's missing. and skype immediately crash with it when try to open camera:-( I hate to say it but I confirm this. Kopete doesn't crash but shows garbage. Should we talk to Fedora-kernel guys? -oget
Re: latest kernel's gspca-kmod missing
--- On Mon, 11/17/08, Hans de Goede wrote: Orcan Ogetbil wrote: [cut] Should we talk to Fedora-kernel guys? No need to do that they are reading along here (atleast I (the webcam dev) am), please see my comment at the end of this bug report which explains the problem and how to work around it: https://bugzilla.redhat.com/show_bug.cgi?id=471726 I'm sorry but a workaround is all I can do for F-9, in F-10 things will work out of the box (except skype, that will still require the workaround). Regards, Hans Thanks for the workaround. It works :) I appreciate your work. -oget
Re: suns' java leagal issues
--- On Mon, 11/17/08, Conrad Meyer wrote: Just a guess -- I'd guess there's a either a no redistribution or non-commercial only redistribution clause, either of which is a no go. non-commercial only is a restriction on the freedom of the software. I don't think this causes a problem with putting it into the non-free repo. We already have non-commercial only software in the non-free repo. Well, we have to read Sun's user agreement to see if it is OK to redistribute it. If it allows redistribution I vote for distributing the RPM in rpmfusion. Btw, I recently checked adobe's flash agreement. That one definitely forbids redistribution. -oget
Re: suns' java leagal issues
--- On Mon, 11/17/08, Conrad Meyer wrote: On Monday 17 November 2008 05:32:07 pm Orcan Ogetbil wrote: Here are the license texts: JRE: http://java.sun.com/javase/6/jre-6u10-license.txt JDK: http://java.sun.com/javase/6/jdk-6u10-license.txt Part B's are about redistribution. They allow redistribution provided that there are no modifications. I'd imagine putting it into an RPM counts as modification. Let's go through the requirements one-by-one (Software refers to Sun's Java): -- (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs, The Software won't be modified. We are just going to put a wrap around their tarball. -- (ii) the Programs add significant and primary functionality to the Software, This is definitely satisfied. Out of question. -- (iii) you do not distribute additional software intended to replace any component(s) of the Software, We are not going to distribute additional software to replace Sun's Java. -- (iv) you do not remove or alter any proprietary legends or notices contained in the Software, Quite doable. -- (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and Actually, we'll put the very same license text in the RPM -- (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. We won't really damage anything that is in their tarball. As I said, we'll just put a gift wrap around it :) -oget
Re: Broken deps - RPM Fusion free Fedora development - 2008-10-24
rt2860-1.8.0.0-1.fc10.noarch requires rt2860-kmod = 0:1.8.0.0 rt2870-1.4.0.0-2.fc10.noarch requires rt2870-kmod = 0:1.4.0.0 rt2860-1.8.0.0-1.fc10.noarch requires rt2860-kmod = 0:1.8.0.0 rt2870-1.4.0.0-2.fc10.noarch requires rt2870-kmod = 0:1.4.0.0 These guys are waiting for a bugfix in fedora kernel. Any news on this, knurd? -oget
Re: Import plans for freshrpms packages; please review!
--- On Fri, 10/17/08, Matthias Saou [EMAIL PROTECTED] wrote: From: Matthias Saou [EMAIL PROTECTED] Subject: Re: Import plans for freshrpms packages; please review! To: Thorsten Leemhuis [EMAIL PROTECTED] Cc: RPM Fusion developers discussion list rpmfusion-developers@lists.rpmfusion.org Date: Friday, October 17, 2008, 5:04 AM Hi everyone, -cut- xmms-aac - import xmms-wma - import Hmmm, gtk1 xmms should die. This is only encouraging it to stick around ;-) I disagree with you at an utmost level. I still think that it is one of the top audio players, if not the best one. If no one wants to maintain it I will take these plugins over without hesitation. -oget __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Yet again: Current package status updated
--- On Tue, 10/7/08, Orcan Ogetbil [EMAIL PROTECTED] wrote: From: Orcan Ogetbil [EMAIL PROTECTED] Subject: Re: Yet again: Current package status updated To: RPM Fusion developers discussion list rpmfusion-developers@lists.rpmfusion.org Date: Tuesday, October 7, 2008, 7:13 PM --- On Tue, 10/7/08, Xavier Lamien [EMAIL PROTECTED] wrote: From: Xavier Lamien [EMAIL PROTECTED] Subject: Re: Yet again: Current package status updated To: [EMAIL PROTECTED], RPM Fusion developers discussion list rpmfusion-developers@lists.rpmfusion.org Date: Tuesday, October 7, 2008, 6:56 PM On Wed, Oct 8, 2008 at 12:47 AM, Orcan Ogetbil [EMAIL PROTECTED] wrote: orphaned | KmPg2 | Not found in free-devel orphaned | KmPg2 | Not found in free-F-8 orphaned | KmPg2 | Not found in free-F-9 orphaned | mamory | Not found in free-devel orphaned | mamory | Not found in free-F-8 orphaned | mamory | Not found in free-F-9 orphaned | mupen64 | Not found in free-devel orphaned | mupen64 | Not found in free-F-8 orphaned | mupen64 | Not found in free-F-9 - Anyone interested? I can take these over if there's demand. If you really want to take them over, please go on and ask for CVS request. -- Xavier.t Lamien -- Interested? Yes for KmPg2 and mupen64. Not that much for mamory but like I said I'll do it if there is demand. Do they need to go through package review process in bugzilla? Or else, where should the CVS request be filed? -oget I understand that the above message of mine might have brought some confusion although I tried to explain my thoughts in a later message. Let me clear up things once and for all. First of all, as of now, I don't own these packages. They are still orphans. 2 of these projects (KmPg2 and mupen64) seem dead to me. No activity for more that 2 years. - We already provide more recent mpeg encoding GUI software (e.g. avidemux) that has more-or-less the same functions. KmPg2 will need patched to work with our ffmpeg. I don't think keeping it is worth the trouble of hacking the code. - I can support mupen64 but it's for i386 only. Thus I can't test the package easily. Also I don't own any software to run on this emulator. - About mamory: I, for one, am just not interest in it. The only problem we will encounter is the mupen64 dependency of mythgame-emulators package, which should be fixable (Don't we have mythgame-emulators for non-i386 systems? How do they work this out?). My own thoughts point in the way that we should consider supporting these 3 packages only if - there is some package that we (will) want to support that depends on some of these 3 packages, or - a packager really wants to keep some of them (that's not me), or - the userbase requests it. Until then -I think- we should put them on the shelf. -oget
Re: Nvidia drivers problem
--- On Sat, 10/11/08, Mario Chacon [EMAIL PROTECTED] wrote: From: Mario Chacon [EMAIL PROTECTED] Subject: Nvidia drivers problem To: RPM Fusion developers discussion list rpmfusion-developers@lists.rpmfusion.org Date: Saturday, October 11, 2008, 12:35 PM Hi! When i try to compli nvidia kmod i get this error, Can i do something to fix it? Also ...where is Xorg in F10??? it's not in /etc/X11. [EMAIL PROTECTED] ~]$ sudo /etc/init.d/nvidia reload Checking for module nvidia.ko: [ OK ] Enabling the nvidia driver: Traceback (most recent call last): File /usr/sbin/nvidia-config-display, line 146, in module app = nvidiaConfigDisplay() File /usr/sbin/nvidia-config-display, line 35, in __init__ GlxConfig.__init__(self) File /usr/lib/python2.5/site-packages/livnaConfigDisplay/GlxConfig.py, line 41, in __init__ LivnaConfigDisplay.__init__(self, isVerbose) File /usr/lib/python2.5/site-packages/livnaConfigDisplay/ConfigDisplay.py, line 45, in __init__ raise livnaConfigDisplayError(XORG_NOT_FOUND) livnaConfigDisplay.livnaConfigDisplayError: Could not read the Xorg configuration file. Please make sure the configuration exists and it is correctly installed. [FAILED] Salu2... The xorg.conf file is not *needed* anymore in F-10. The X-server will determine the parameters by itself. But if there *is* a xorg.conf file X-server will use it. Since the proprietary nvidia drivers need a xorg.conf file in most scenarios, I think a generic one needs to be built via system-config-display --reconfig, possibly in %post. -oget
Re: Problem with import script
--- On Tue, 10/7/08, Xavier Lamien [EMAIL PROTECTED] wrote: From: Xavier Lamien [EMAIL PROTECTED] Subject: Re: Problem with import script To: RPM Fusion developers discussion list rpmfusion-developers@lists.rpmfusion.org Date: Tuesday, October 7, 2008, 4:11 PM On Tue, Oct 7, 2008 at 9:04 PM, Andrea Musuruane [EMAIL PROTECTED] wrote: 2008/10/5 Andrea Musuruane [EMAIL PROTECTED]: Hi, I just tried to import e-uae to nonfree, but I get the following error: $ ./cvs-import.sh -b devel /home/andrea/rpmbuild/SRPMS/e-uae-0.8.29-0.10.wip4.fc9.src.rpm Checking out module: 'e-uae' Unpacking source package: e-uae-0.8.29-0.10.wip4.fc9.src.rpm... L e-uae-0.8.29-WIP4.tar.bz2 A e-uae-0.8.29-execstack.patch A e-uae-0.8.29-hardfilefixes.patch A e-uae-0.8.29-irqfixes.patch A e-uae.png A e-uae.spec Checking : e-uae-0.8.29-WIP4.tar.bz2 on https://cvs.rpmfusion.org/repo/pkgs/upload.cgi... Module 'e�-uae' does not exist! make: *** [upload] Error 1 ERROR: Uploading the source tarballs failed! A note for Thorsten: I still get the same error. I cannot see any changes in the common directory. Maybe you applied your patch only in the free branch? I'm working on it. btw, do you have the src.rpm file hosted somewhere ? -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB Not related to this query but I think one should do a sed 's/rpomfusion/rpmfusion/' to the import script.
Re: Yet again: Current package status updated
--- On Tue, 10/7/08, Xavier Lamien [EMAIL PROTECTED] wrote: From: Xavier Lamien [EMAIL PROTECTED] Subject: Re: Yet again: Current package status updated To: [EMAIL PROTECTED], RPM Fusion developers discussion list rpmfusion-developers@lists.rpmfusion.org Date: Tuesday, October 7, 2008, 6:56 PM On Wed, Oct 8, 2008 at 12:47 AM, Orcan Ogetbil [EMAIL PROTECTED] wrote: orphaned | KmPg2 | Not found in free-devel orphaned | KmPg2 | Not found in free-F-8 orphaned | KmPg2 | Not found in free-F-9 orphaned | mamory | Not found in free-devel orphaned | mamory | Not found in free-F-8 orphaned | mamory | Not found in free-F-9 orphaned | mupen64 | Not found in free-devel orphaned | mupen64 | Not found in free-F-8 orphaned | mupen64 | Not found in free-F-9 - Anyone interested? I can take these over if there's demand. If you really want to take them over, please go on and ask for CVS request. -- Xavier.t Lamien -- Interested? Yes for KmPg2 and mupen64. Not that much for mamory but like I said I'll do it if there is demand. Do they need to go through package review process in bugzilla? Or else, where should the CVS request be filed? -oget
Re: Yet again: Current package status updated
Interested? Yes for KmPg2 and mupen64. Not that much for mamory but like I said I'll do it if there is demand. -oget Correction: -mupen64 seems to work only on i386 and there are no updates on the project home page in the last 3 years. -kmpg2 homepage is dead. From google cache I figure out they didn't have activity for over 2 years. kmpg2 depends on the old kdewebdev-3.5 (I have no idea why). It also seemed to be incompatible with the version of ffmpeg we have in rpmfusion. -mamory: Last update: 1 year ago or so. In short, I'm not a fan of these applications and I wouldn't bother offering them if you'd ask me. Hence I will keep these dribble srpm's on my computer and can provide rpm's in the future if there's a request. -oget
