Re: shotcut needs a rebuild for qt6 version 6.6 for F-38
On Sun, 19 Nov 2023 11:15:42 +0100 Dan Horák via rpmfusion-developers wrote: > Hello, > > seems the shotcut-23.11.04-1.fc38 build has been done with qt6 version > 6.5 in the buildroot, but qt6 has been rebased to 6.6 in the meantime. > The F-39 and Rawhide builds of shotcut look good to me. forgot to attach dnf errors Problem 1: cannot install the best update candidate for package shotcut-23.09.29-1.fc38.ppc64le - nothing provides libQt6Charts.so.6(Qt_6.5_PRIVATE_API)(64bit) needed by shotcut-23.11.04-1.fc38.ppc64le from rpmfusion-free-updates-testing Problem 2: package shotcut-langpack-en-23.11.04-1.fc38.noarch from rpmfusion-free-updates-testing requires shotcut = 23.11.04-1.fc38, but none of the providers can be installed - cannot install the best update candidate for package shotcut-langpack-en-23.09.29-1.fc38.noarch - nothing provides libQt6Charts.so.6(Qt_6.5_PRIVATE_API)(64bit) needed by shotcut-23.11.04-1.fc38.ppc64le from rpmfusion-free-updates-testing Problem 3: package shotcut-langpack-cs-23.11.04-1.fc38.noarch from rpmfusion-free-updates-testing requires shotcut = 23.11.04-1.fc38, but none of the providers can be installed - cannot install the best update candidate for package shotcut-langpack-cs-23.09.29-1.fc38.noarch - nothing provides libQt6Charts.so.6(Qt_6.5_PRIVATE_API)(64bit) needed by shotcut-23.11.04-1.fc38.ppc64le from rpmfusion-free-updates-testing BTW this is not ppc64le specific, both aarch64 and x86_64 require libQt6Charts.so.6(Qt_6.5_PRIVATE_API)(64bit) as well Dan ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
shotcut needs a rebuild for qt6 version 6.6 for F-38
Hello, seems the shotcut-23.11.04-1.fc38 build has been done with qt6 version 6.5 in the buildroot, but qt6 has been rebased to 6.6 in the meantime. The F-39 and Rawhide builds of shotcut look good to me. Thanks, Dan ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld
On Tue, 2 Jan 2018 14:24:31 +0100 Nicolas Chauvet wrote: > 2018-01-02 12:53 GMT+01:00 Kevin Kofler : > > Sérgio Basto wrote: > .. > > The only other solution would be for RPM Fusion to get faster > > 32-bit ARM builders, but it doesn't look like that is going to > > happen any time soon, unfortunately. > > Few things: > > What's annoying in this situation is more that the armv7hl build > failed than that it took time to build. > For this specific issue, I (one?) can probably find the option to > raise the koji task timeout. it should be rpmbuild_timeout in kojid.conf, which gets translated to a mock option Dan ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [leftovers] FTBFS in F26
On Sun, 30 Apr 2017 14:21:39 +0200 Alexandre Moine wrote: > Le 17 avril 2017 00:17:32 GMT+02:00, "Sérgio Basto" > a écrit : > >Hello > > > >These packages are the remain packages that not build in F26 mass- > >rebuild > > > > > >openmw-0.41.0-2.fc26 > >pdflib-lite-7.0.5-10.fc26 (rfbz #3891) > >simplescreenrecorder-0.3.8-2.fc26 > >stella-4.7.3-2.fc26 > >bombono-dvd-1.2.4-3.fc26 > >mythtv-0.28.1-2.fc26 > > > >new: (I added the source with rfpkg new-sources today) > >tarsnap-1.0.36.1-2.fc26 , openssl 1.1 related. > > > >I'm building assaultcube now which also upload the sources today ... > > > >Cheers, > >-- > >Sérgio M. B. > >___ > >rpmfusion-developers mailing list -- > >rpmfusion-developers@lists.rpmfusion.org > >To unsubscribe send an email to > >rpmfusion-developers-le...@lists.rpmfusion.org > > Hi, > > I filled a bug for openmw: > https://bugzilla.rpmfusion.org/show_bug.cgi?id=4524 > > For information, openmw is knew to have problem on Big Indiana CPU > (https://bugs.openmw.org/issues/564 ). > > I don't see any interest in having such a game on ppc64... > > Does-it seems a good idea to exclude this arch ? yes, it fine to Exclude ppc64 Dan ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: avidemux and gcc6
On Mon, 11 Jul 2016 06:32:48 -0500 Richard Shaw wrote: > On Monday, July 11, 2016, Dan Horák wrote: > > > Hi, > > > > because I wanted avidemux on F-24 I've spend some time to find the > > missing gcc6 fixes, see the result in > > http://fedora.danny.cz/avidemux-2.6.12-gcc6.patch > > It now builds under F-24 mock. > > > > > > Mostly cherry-picked from > > > > https://github.com/mean00/avidemux2/commit/68df30b902540e6f299dc63ea3ae53b3d353cbe4 > > but also > > > > https://github.com/mean00/avidemux2/commit/7dee579d3ac16d731898305d24bb771834ae0ce0 > > > > https://github.com/mean00/avidemux2/commit/6ad028d9f9caf929819c1afcb693611aade0af0b > > > > Hah! I was working on that to until I ran into a narrowing conversion > I couldn't fix. I'm at camp with my son for the week so it will > likely be early next week before I can do anything It took me quite a number of iterations to get there, but fortunately upstream already has all the fixes. Looks like I'm not a proven-packager for rpmfusion, if such role exists, only regular packager. Maybe someone else can push it. Dan
avidemux and gcc6
Hi, because I wanted avidemux on F-24 I've spend some time to find the missing gcc6 fixes, see the result in http://fedora.danny.cz/avidemux-2.6.12-gcc6.patch It now builds under F-24 mock. Mostly cherry-picked from https://github.com/mean00/avidemux2/commit/68df30b902540e6f299dc63ea3ae53b3d353cbe4 but also https://github.com/mean00/avidemux2/commit/7dee579d3ac16d731898305d24bb771834ae0ce0 https://github.com/mean00/avidemux2/commit/6ad028d9f9caf929819c1afcb693611aade0af0b Dan
Re: rpms/OCE/devel OCE.spec,1.4,1.5
Nicolas Chauvet píše v Po 18. 02. 2013 v 23:03 +0100:
> 2013/2/18 Richard Shaw
>
> > On Mon, Feb 18, 2013 at 3:26 PM, Nicolas Chauvet
> > wrote:
> >
> > > 2013/2/18 Richard Shaw
> > >>
> > >> Author: hobbes1069
> > >>
> > >> Update of /cvs/nonfree/rpms/OCE/devel
> > >> In directory old02.ovh.rpmfusion.lan:/tmp/cvs-serv29040
> > >>
> > >> Modified Files:
> > >> OCE.spec
> > >> Log Message:
> > >> * Mon Feb 18 2013 Richard Shaw - 0.11-2
> > >> - Add tbb-devel as build requirement.
> > >
> > > Really that's only %{ix86} x86_64 ia64 not any other way...
> > > (Use %ifarch %{ix86} x86_64 ia64 )
> >
> > I used %ifnarch %arm...
> >
> > Since powerpc has tbb, I didn't want to exclude building against tbb
> > on that platform, no?
> >
> My bad, it's also available on ppc ppc64 and but on s390, anyway it's
> probably safer to allow only on known arches instead of excluded arches
> assuming a safer default.
yes, if TBB uses ExclusiveArch: in Fedora then packages depending
on it should also use the "positive list" - %ifarch
Dan
Re: buildsystem mame
Dan Horák píše v So 27. 10. 2012 v 12:48 +0200:
> Nicolas Chauvet píše v So 27. 10. 2012 v 12:40 +0200:
> > Yesterday.
> > Le 27 oct. 2012 10:43, "Julian Sikorski" a écrit :
> > >
> > > W dniu 11.10.2012 07:28, Julian Sikorski pisze:
> > > > W dniu 11.10.2012 00:27, Nicolas Chauvet pisze:
> > > >> 2012/10/10 Julian Sikorski <
> > belegdol-re5jqeeqqe8avxtiumwx3w-xmd5yjdbdmrexy1tmh2...@public.gmane.org>:
> > > >>> W dniu 2012-10-10 12:22, Leigh Scott pisze:
> > > >>>>
> > > >>>> Hi Julian,
> > > >>>>
> > > >>>>
> > > >>>>> If I could somehow force only one build at a
> > > >>>>> time, this could help. Otherwise we might need to bump the builder
> > > >>>>> memory - how much does it have now?
> > > >> That's the point, the builder is lacking memory, but only during link
> > > >> time of a given build.
> > > >> I've reproduced the problem on a similar builder. I will try to
> > > >> reproduce using a f18 target.
> > > >>
> > > >> Please do not submit any mame jobs for now.
> > > >> Thx
> > > >>
> > > >> Nicolas (kwizart)
> > > >>
> > > > Sure, no problem. If the memory is the only issue, I can consider
> > > > donating some. Let me know what your tests show and what type of memory
> > > > is needed.
> > > >
> > > > Julian
> > > >
> > > Where do we stand on this? If RPM Fusion is no longer able to supply
> > > up-to-date mame packages, I need to look for another solution.
> > >
> > > Regards,
> > > Julian
> >
> > Hi Julian,
> >
> > I was only able to test a f18 target
> > Yesterday. And it has failed the same as f19.
> >
> > There are actions ongoing to solve this from the infra side.
> >
> > Btw. Is there a way to lower the memory usage needed at link time until the
> > problem is solved ?
>
> the trick used in Fedora on s390/ppc/arm for some packages (webkit, ...)
> was to switch from -g to -g1 (generates less debuginfos) and use
> "-Wl,--no-keep-memory -Wl,--reduce-memory-overheads"
> options for the linker
and it looks like this:
%build
%ifarch s390 %{arm}
# Use linker flags to reduce memory consumption on low-mem architectures
%global optflags %{optflags} -Wl,--no-keep-memory -Wl,--reduce-memory-overheads
%endif
%ifarch s390
# Decrease debuginfo verbosity to reduce memory consumption even more
%global optflags %(echo %{optflags} | sed 's/-g/-g1/')
%endif
Dan
Re: buildsystem mame
Nicolas Chauvet píše v So 27. 10. 2012 v 12:40 +0200: > Yesterday. > Le 27 oct. 2012 10:43, "Julian Sikorski" a écrit : > > > > W dniu 11.10.2012 07:28, Julian Sikorski pisze: > > > W dniu 11.10.2012 00:27, Nicolas Chauvet pisze: > > >> 2012/10/10 Julian Sikorski < > belegdol-re5jqeeqqe8avxtiumwx3w-xmd5yjdbdmrexy1tmh2...@public.gmane.org>: > > >>> W dniu 2012-10-10 12:22, Leigh Scott pisze: > > > > Hi Julian, > > > > > > > If I could somehow force only one build at a > > > time, this could help. Otherwise we might need to bump the builder > > > memory - how much does it have now? > > >> That's the point, the builder is lacking memory, but only during link > > >> time of a given build. > > >> I've reproduced the problem on a similar builder. I will try to > > >> reproduce using a f18 target. > > >> > > >> Please do not submit any mame jobs for now. > > >> Thx > > >> > > >> Nicolas (kwizart) > > >> > > > Sure, no problem. If the memory is the only issue, I can consider > > > donating some. Let me know what your tests show and what type of memory > > > is needed. > > > > > > Julian > > > > > Where do we stand on this? If RPM Fusion is no longer able to supply > > up-to-date mame packages, I need to look for another solution. > > > > Regards, > > Julian > > Hi Julian, > > I was only able to test a f18 target > Yesterday. And it has failed the same as f19. > > There are actions ongoing to solve this from the infra side. > > Btw. Is there a way to lower the memory usage needed at link time until the > problem is solved ? the trick used in Fedora on s390/ppc/arm for some packages (webkit, ...) was to switch from -g to -g1 (generates less debuginfos) and use "-Wl,--no-keep-memory -Wl,--reduce-memory-overheads" options for the linker Dan
Re: rpms/openmotif/devel openmotif.spec,1.4,1.5 sources,1.3,1.4
Nicolas Chauvet píše v Čt 25. 10. 2012 v 21:46 +0200:
> 2012/10/25 Jochen Schmitt :
> > Author: s4504kr
>
> > --- openmotif.spec 5 Jun 2012 21:14:46 - 1.4
> > +++ openmotif.spec 25 Oct 2012 19:15:15 - 1.5
> > @@ -1,15 +1,13 @@
> > -%global major 2.3
> > Summary: Open Motif runtime libraries and executables
> > Name: openmotif
> > -Version: %{major}.3
> > -Release: 3%{?dist}
> > -License: Open Group Public License
> > +Version: 2.3.4
> > +Release: 1%{?dist}
> > +License: LGPLv2+
>
> Hi Jochen,
>
> Doesn't that mean openmotif can go into Fedora ?
it is already on the way to Fedora -
https://bugzilla.redhat.com/show_bug.cgi?id=870049
Dan
Re: OpenCascade license?
Richard Shaw píše v Po 19. 12. 2011 v 12:27 -0600: > On Sat, Dec 10, 2011 at 4:52 AM, Dan Horák wrote: > > yes, I am, taking for review now > > Ok, now that you've approved it I need your RPM Fusion account name to > add as a co-maintainer :) My account is sharkcz. And thanks for the packaging work :-) Dan
Re: OpenCascade license?
Richard Shaw píše v St 07. 12. 2011 v 15:22 -0600: > Dan, > > Are you still interested in reviewing this package? > > https://bugzilla.rpmfusion.org/show_bug.cgi?id=2054 > > Version 0.8.0 is about to be released which includes patches I got > upstreamed. (Yay for for packages that build with zero patches!) yes, I am, taking for review now Dan
Re: OpenCascade license?
Richard Shaw píše v Po 14. 11. 2011 v 16:09 -0600: > Dan, > > I'm cleaning up the spec file getting it ready for submission. Are you > interested in reviewing and co-maintaining OCE rather than OCC? Sure, I am interested. Do you know if there is a clean relation between OCC releases (and thus API) and OCE versions? Dan
Re: OpenCascade license?
Richard Shaw píše v So 05. 11. 2011 v 09:03 -0500: > I finally got it to build! that's great news > I had to go through the debian *.install files to clean up all the > %files sections as there were a lot of libraries removed and a couple > added. > > Let me know if you're still interested. yes, I am What remains is who should submit it for review? You skills are definitely high enough for being the owner. I can help as reviewer and co-maintainer. Would it work for you? Dan
Re: OpenCascade license?
Richard Shaw píše v Čt 03. 11. 2011 v 07:46 -0500: > On Thu, Nov 3, 2011 at 6:00 AM, Dan Horák wrote: > > Richard Shaw píše v Út 01. 11. 2011 v 08:57 -0500: > >> On Mon, Oct 31, 2011 at 4:31 PM, Dan Horák wrote: > >> > Richard Shaw píše v Po 31. 10. 2011 v 16:16 -0500: > >> >> I'm taking a shot a building FreeCAD since I'm a CAD jockey in my day > >> >> job and a "good" free CAD solution would be neat. > >> >> > >> >> It has OpenCascade as a major dependency, which uses their own > >> >> license[1]. They claim it's LGPL-like. Would this have to go in free > >> >> or non-free? > >> > > >> > per Tom "Spot" Callaway and Red Hat Legal it is non-free, you should be > >> > able to find the details in the archive of the fedora-legal mailing list > >> > and/or OCC package review request in Fedora bugzilla. > >> > > >> > OCC 6.3.0 is available from http://fedora.danny.cz/danny/ and it would > >> > be nice to see OCC in a more official repo. > >> > >> Well I took a look at your source package. Do you have any interest in > >> maintaining it in RPM Fusion? > > > > That was the original plan, but as you can see the package is still in > > version 6.3.0 while upstream (and Debian) has 6.5.0 already. > > Unfortunately I got quite busy with other work so I couldn't give OCC > > the needed care. > > > >> The reason I ask is I noticed the large number of patches that I'm not > >> sure I'm even qualified to maintain. I see some minor things that need > >> to be changed in the spec but overall it's in very good shape. > > > > The community around OCC is much alive in Debian, so I took the patches > > mainly from them, some are mine and they were sent to Debian. OCC is a > > large package and sharing the work is really necessary. The structure > > how are the libraries divided into subpackages is also copied from > > Debian, with the exception that there is only one devel subpackage. > > I'll see if I can dig up the updated patches from them then. I > downloaded the new 6.5.1 source which I noticed was about twice the > size of the one in your SRPM. Did you remove some parts of the source? > For instance, windows only portions or pre-compiled portions? Oh, they started to release also the micro bugfix releases, that's nice :-) I have used the upstream source archive, while the Debian folks drop a lot of stuff from it (see http://ftp.debian.org/debian/pool/main/o/opencascade/). I think the main difference against 6.3.0 is in the size of documentation which is pre-built. I will try to look at the 6.5.1 too, but can't promise any dates. Dan
Re: OpenCascade license?
Richard Shaw píše v Út 01. 11. 2011 v 08:57 -0500: > On Mon, Oct 31, 2011 at 4:31 PM, Dan Horák wrote: > > Richard Shaw píše v Po 31. 10. 2011 v 16:16 -0500: > >> I'm taking a shot a building FreeCAD since I'm a CAD jockey in my day > >> job and a "good" free CAD solution would be neat. > >> > >> It has OpenCascade as a major dependency, which uses their own > >> license[1]. They claim it's LGPL-like. Would this have to go in free > >> or non-free? > > > > per Tom "Spot" Callaway and Red Hat Legal it is non-free, you should be > > able to find the details in the archive of the fedora-legal mailing list > > and/or OCC package review request in Fedora bugzilla. > > > > OCC 6.3.0 is available from http://fedora.danny.cz/danny/ and it would > > be nice to see OCC in a more official repo. > > Well I took a look at your source package. Do you have any interest in > maintaining it in RPM Fusion? That was the original plan, but as you can see the package is still in version 6.3.0 while upstream (and Debian) has 6.5.0 already. Unfortunately I got quite busy with other work so I couldn't give OCC the needed care. > The reason I ask is I noticed the large number of patches that I'm not > sure I'm even qualified to maintain. I see some minor things that need > to be changed in the spec but overall it's in very good shape. The community around OCC is much alive in Debian, so I took the patches mainly from them, some are mine and they were sent to Debian. OCC is a large package and sharing the work is really necessary. The structure how are the libraries divided into subpackages is also copied from Debian, with the exception that there is only one devel subpackage. Dan
Re: OpenCascade license?
Richard Shaw píše v Po 31. 10. 2011 v 16:16 -0500: > I'm taking a shot a building FreeCAD since I'm a CAD jockey in my day > job and a "good" free CAD solution would be neat. > > It has OpenCascade as a major dependency, which uses their own > license[1]. They claim it's LGPL-like. Would this have to go in free > or non-free? per Tom "Spot" Callaway and Red Hat Legal it is non-free, you should be able to find the details in the archive of the fedora-legal mailing list and/or OCC package review request in Fedora bugzilla. OCC 6.3.0 is available from http://fedora.danny.cz/danny/ and it would be nice to see OCC in a more official repo. Dan
Re: avidemux: need some programming help
Richard Shaw píše v St 01. 06. 2011 v 11:28 -0500: > Ok, so something in the new js (1.8.5) broke avidemux in Fedora 15[1] > and I'm in over my head so some direction would be appreciated. The > only error info I have from the build log is: I have seen js-1.8.5-related patches in some packages in Fedora (eg. callweaver, but everything that depends on js-devel could have a patch), it could help you with porting avidemux. Dan
Re: x264 ABI bump in rawhide
Nicolas Chauvet píše v Pá 09. 07. 2010 v 09:50 +0200: > 2010/7/8 Dan Horák : > > Dominik 'Rathann' Mierzejewski píše v Út 06. 07. 2010 v 21:00 +0200: > >> Hi all > >> > > > >> Out of these, libquicktime doesn't build because of gtk2 changes in > >> rawhide: > >> libquicktime_config.c: In function 'create_main_window': > >> libquicktime_config.c:115: warning: implicit declaration of function > >> 'GTK_OBJECT_FLAGS' > >> libquicktime_config.c:115: error: lvalue required as left operand of > >> assignment > >> libquicktime_config.c:116: error: lvalue required as left operand of > >> assignment > >> lqt_gtk.c: In function 'lqtgtk_create_codec_config_window': > >> lqt_gtk.c:944: warning: implicit declaration of function 'GTK_OBJECT_FLAGS' > >> lqt_gtk.c:944: error: lvalue required as left operand of assignment > >> lqt_gtk.c:945: error: lvalue required as left operand of assignment > >> lqt_gtk.c:946: error: lvalue required as left operand of assignment > >> lqt_gtk.c: In function 'lqtgtk_create_codec_info_window': > >> lqt_gtk.c:1243: error: lvalue required as left operand of assignment > > > > update for recent GTK is attached, they don't have any bug/patch tracker > > on sf.net > > > > > > Dan > Dan, > > I saw you patch, I think it would be more interesting if you can > commit it yourself. So I will open-up your commit right on > libquicktime. I wasn't able to commit the patch during the weekend. Is such opening even possible in RPM Fusion? > For the re > > Just for a remind, I'm more concerned by the work needed in F-13 > Dan
Re: x264 ABI bump in rawhide
Dominik 'Rathann' Mierzejewski píše v Út 06. 07. 2010 v 21:00 +0200: > Hi all > > Out of these, libquicktime doesn't build because of gtk2 changes in > rawhide: > libquicktime_config.c: In function 'create_main_window': > libquicktime_config.c:115: warning: implicit declaration of function > 'GTK_OBJECT_FLAGS' > libquicktime_config.c:115: error: lvalue required as left operand of > assignment > libquicktime_config.c:116: error: lvalue required as left operand of > assignment > lqt_gtk.c: In function 'lqtgtk_create_codec_config_window': > lqt_gtk.c:944: warning: implicit declaration of function 'GTK_OBJECT_FLAGS' > lqt_gtk.c:944: error: lvalue required as left operand of assignment > lqt_gtk.c:945: error: lvalue required as left operand of assignment > lqt_gtk.c:946: error: lvalue required as left operand of assignment > lqt_gtk.c: In function 'lqtgtk_create_codec_info_window': > lqt_gtk.c:1243: error: lvalue required as left operand of assignment update for recent GTK is attached, they don't have any bug/patch tracker on sf.net Dan diff -up libquicktime-1.1.5/utils/gtk/libquicktime_config.c.gtk libquicktime-1.1.5/utils/gtk/libquicktime_config.c --- libquicktime-1.1.5/utils/gtk/libquicktime_config.c.gtk 2010-07-08 12:21:24.0 +0200 +++ libquicktime-1.1.5/utils/gtk/libquicktime_config.c 2010-07-08 12:22:45.0 +0200 @@ -112,8 +112,8 @@ static MainWindow * create_main_window() G_CALLBACK(main_window_button_callback), (gpointer)ret); - GTK_WIDGET_SET_FLAGS (ret->close_button, GTK_CAN_DEFAULT); - GTK_WIDGET_SET_FLAGS (ret->save_button, GTK_CAN_DEFAULT); + gtk_widget_set_can_default(GTK_WIDGET(ret->close_button), TRUE); + gtk_widget_set_can_default(GTK_WIDGET(ret->save_button), TRUE); gtk_widget_show(ret->close_button); gtk_widget_show(ret->save_button); diff -up libquicktime-1.1.5/utils/gtk/lqt_gtk.c.gtk libquicktime-1.1.5/utils/gtk/lqt_gtk.c --- libquicktime-1.1.5/utils/gtk/lqt_gtk.c.gtk 2010-07-08 12:27:26.0 +0200 +++ libquicktime-1.1.5/utils/gtk/lqt_gtk.c 2010-07-08 12:27:04.0 +0200 @@ -941,9 +941,9 @@ lqtgtk_create_codec_config_window(lqt_co G_CALLBACK(codec_config_window_button_callback), (gpointer)ret); - GTK_WIDGET_SET_FLAGS (ret->apply_button, GTK_CAN_DEFAULT); - GTK_WIDGET_SET_FLAGS (ret->close_button, GTK_CAN_DEFAULT); - GTK_WIDGET_SET_FLAGS (ret->restore_button, GTK_CAN_DEFAULT); + gtk_widget_set_can_default(GTK_WIDGET(ret->apply_button), TRUE); + gtk_widget_set_can_default(GTK_WIDGET(ret->close_button), TRUE); + gtk_widget_set_can_default(GTK_WIDGET(ret->restore_button), TRUE); gtk_widget_show(ret->apply_button); gtk_widget_show(ret->close_button); @@ -1240,7 +1240,7 @@ lqtgtk_create_codec_info_window(const lq ret->mainbox = gtk_vbox_new(0, 10); ret->close_button = gtk_button_new_from_stock(GTK_STOCK_CLOSE); - GTK_WIDGET_SET_FLAGS (ret->close_button, GTK_CAN_DEFAULT); + gtk_widget_set_can_default(GTK_WIDGET(ret->close_button), TRUE); g_signal_connect(G_OBJECT(ret->close_button), "clicked", G_CALLBACK(codec_info_window_button_callback),
Re: How to move on with infrastructure?
Thorsten Leemhuis píše v St 21. 10. 2009 v 20:27 +0200: > Hi! > > 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: > > - our infrastructure team basically consists of just one person: Xavier > Lamien (laxathom/SmootherFrOgZ) > > - 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 > > - we have a x86-64 builder that isn't used since a few weeks (months?) > > - we afaik were asked to migrate to a different ppc builder but that > work stalled > > - using koji and bodhi for RPM Fusion is something that people are > asking for every few weeks I have setup my private Koji instance connected to Fedora using the external repo feature and played a bit with mash. I have also some know how from Fedora secondary archs about using distributed Koji architecture with remote builders. So I'm offering my help in this area. > - there are multiple small problems (often not in bugzilla) that are > annoying, but not pressing (no automatic rebuilds, no repoclosure > scripts, repodata regeneration after push, incomplete delta-rpm support > are some of them, out-of-diskspace situations, some builders use mock > caching while others do not, rawhide out of date on of of the builders, ...) > > > So how to we fix all of the above to make sure RPM Fusion gets more > healthy over time? Dan
Re: mirrors.rpmfusion.org update
Adrian Reber píše v Po 19. 10. 2009 v 11:16 +0200: > I will update RPM Fusion's mirrormanager installation. To make the > update a bit easier the DNS entry for mirrors.rpmfusion.org will > temporarily point to only one mirrorlist server instead of the usual > two. > > In theory the update should not cause any problems but if someone sees > something unusual please let me know (here or on #rpmfusion). Does the RPM Fusion's MirrorManager allow private mirrors to be registered like Fedora's one? Dan
Re: Spectrum ROMs in RPM Fusion
Jussi Lehtola píše v So 25. 07. 2009 v 22:02 +0300: > On Sat, 2009-07-25 at 17:45 +0200, Andrea Musuruane wrote: > > Hi all, > > I'm going to submit FBZX, a Spectrum emulator, for review in Fedora. > > > > Fedora allows the packaging of Spectrum emulators but it doesn't allow > > Spectrum ROMs, even though they are distributable. Therefore I'll have > > to remove the ROMs from the tarball as it is currently done by > > fuse-emulator. Just a note - if an otherwise free and acceptable for fedora emulator can't work (or do something useful) without a non-free firmware or ROM then such emulator can't be accepted into fedora. > > Since there is just one Spectrum emulator in Fedora, the required ROMs > > are currently shipped in RPM Fusion by the package fuse-emulator-roms. > > > > My idea is to make a package called spectrum-roms and submit it for > > inclusion in RPM Fusion. All packaged Spectrum emulators will have to > > be patched to find the required ROMs under /usr/share/spectrum-roms/ > > and should have a README.Fedora file that should forward the user to > > RPM Fusion to install spectrum-roms. Probably it will also be a good > > idea to document this on RPM Fusion wiki. > > I don't think you can mention RPMFusion in a README.Fedora, that is > probably against policy. You can put a general note that one must get > the ROMs from someplace and place them in /usr/share/spectrum-roms/ > though. > An another question is which package should own the aforementioned > directory; it might be best to make all Spectrum emulators own it. Dan
Re: BRing qt3 on both fedora and EPEL
David Timms píše v Pá 03. 04. 2009 v 08:19 +1100:
> 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:
The BRs can be conditionalized like
%if 0%{?fedora} > X
BuildRequires: qt-devel >= 3
%endif
%if 0%{?rhel} > Y
BuildRequires: qt-devel < 4
%endif
and AFAIK the qt-devel package provides qtX-devel, where X in (3, 4)
depending on the version. So if you want to use qt3 on both Fedora and
EPEL then just add "BR: qt3-devel"
Dan
Re: Stronger Hashes
Thorsten Leemhuis píše v Čt 12. 03. 2009 v 10:53 +0100: > On 12.03.2009 10:15, Dan Horák wrote: > > Thorsten Leemhuis píše v St 11. 03. 2009 v 08:15 +0100: > >> On 10.03.2009 19:31, Julian Sikorski wrote: > >>> Thorsten Leemhuis pisze: > >>>> So we got the new rpm and build for i586 now on x86-32. Are any other > >>>> changes needed? Do we want to do a mass rebuild? How: Manual or > >>>> scripted? And are there any big updates pending that we should do before > >>>> starting the mass rebuild (ffmpeg?) > >>> I think we should do a mass rebuild, just as fedora did. > >> BTW (in case that wasn't obvious from my earlier mail): I agree here ;-) > >> > >>> Does the “stronger hashes” feature concern us as well? > >> I'd say it "would be nice to have". But does anyone know what exact > >> steps we need to do to get it? After reading > >> https://www.redhat.com/archives/fedora-announce-list/2009-March/msg4.html > >> http://fedoraproject.org/wiki/Features/StrongerHashes > >> is seems it requires a few changes in different areas of our infra. > >> Somebody afaics need to look into what exactly is needed. Any > >> volunteers? Anyone with a good connection to Fedora intra/Jesse/mitr > >> that could ask for advice? > > I talked to mitr and he is ready answer your questions, he is usually > > online on #fedora-devel. > > Hehe, nice trick ;-) The purpose of my mail was to put the work (or at > least parts of it) on somebodies else todo-list and not on mine (which > is filled with lots of RPM-Fusion-related work already). I thought that > was obvious ;-) He is colleague of mine so I wanted to assure anyone (not only you, but really anyone) that he will be helpful. I am sorry if it could be understood that I expect you should actually do it. > Anyway, no big deal, if nobody steps up then I'll of course do it sooner > or later (not the first time...). Dan
Re: Stronger Hashes (was: Re: Outage Notication: Build System)
Thorsten Leemhuis píše v St 11. 03. 2009 v 08:15 +0100: > On 10.03.2009 19:31, Julian Sikorski wrote: > > Thorsten Leemhuis pisze: > >> So we got the new rpm and build for i586 now on x86-32. Are any other > >> changes needed? Do we want to do a mass rebuild? How: Manual or > >> scripted? And are there any big updates pending that we should do before > >> starting the mass rebuild (ffmpeg?) > > I think we should do a mass rebuild, just as fedora did. > > BTW (in case that wasn't obvious from my earlier mail): I agree here ;-) > > > Does the “stronger hashes” feature concern us as well? > > I'd say it "would be nice to have". But does anyone know what exact > steps we need to do to get it? After reading > https://www.redhat.com/archives/fedora-announce-list/2009-March/msg4.html > http://fedoraproject.org/wiki/Features/StrongerHashes > is seems it requires a few changes in different areas of our infra. > Somebody afaics need to look into what exactly is needed. Any > volunteers? Anyone with a good connection to Fedora intra/Jesse/mitr > that could ask for advice? I talked to mitr and he is ready answer your questions, he is usually online on #fedora-devel. Dan
Re: Where we are and where do we what to go?
Thorsten Leemhuis píše v Út 10. 02. 2009 v 20:43 +0100: > On 10.02.2009 11:48, Dan Horák wrote: > > Thorsten Leemhuis píše v Út 10. 02. 2009 v 10:14 +0100: > >> On 10.02.2009 09:57, Dan Horák wrote: > >>> Thorsten Leemhuis píše v Po 09. 02. 2009 v 19:58 +0100: > >>>> On 09.02.2009 14:28, Dan Horák wrote: > >>>>> Thorsten Leemhuis píše v Ne 08. 02. 2009 v 10:06 +0100: > >>>>>> On 04.02.2009 14:24, Rex Dieter wrote: > >>>>>>> Thorsten Leemhuis wrote: > > [...] > >>> When there should be multiple repos, then I would prefer to divide them > >>> by relation to Fedora/RPM Fusion (eg. experimental, backports) rather > >>> then by area (kde, mono, math, ...) > >> A dedicated "math" repo like really is not needed -- those packages are > >> likely more suitable for a general experimental and/or staging repo. But > >> I guess some sort of spits by area will be needed -- I guess that (for > >> example) the kde-redhat users likely don't want to get highly > >> experimental graphics drivers from the same repo when they run yum-update. > >> repo files are likely way to complicated... > > I should have known it will be complicated, but let's try to categorize > > the possible stuff: > > Not sure yet if I like that scheme. But I'm not even sure if I fully > understand it yet. No problem, it is a discussion. > > - new packages => no conflicts with Fedora/RPM Fusion => 2 repos (stable > > + testing), stable enabled by default > > You mean the normal free and nonfree repos we already have? This should be a place for packages that the submitter has created, can update them sometimes, but he is not willing to submit them for official review. The reasons can be lack of hardware or time, loss of interest, etc. But the packages exist and everybody is encouraged to grab them and officially submit them on his own. It can even be used for packages that are waiting for review or just undergoing the review, because the whole process can last many months. > Side note: Should we split free and nonfree for those experimental areas > as well? I tend to say "no", as that might complicate things to much > (CVS, pushing, configuration for users, yum overhead, ...) . > > > - existing packages > > - experimental > > - examples: codeblocks > > /me tries to get the example > > Ahh, codeblocks is one of you Fedora packages! > > /me thinks he got it now Sorry, I should have been more concrete - codeblocks has very few releases, I dare to say one in many years, but I want to stick by the releases for Fedora. The upstream releases so called "nightly snapshots" time after time that can be interesting for some users and the developers will appreciate any feedback on them. > > - backports > > - examples: > > - forwardports (new stable versions from Fedora into EL) > > - examples: zabbix (no rebase 1.4->1.6 planned due DB > > changes etc, but some users would appreciate to have > > the 1.6) > > > > - one repo for each category, disabled by default, user > > must manually enable the repo and pick the package he > > want to install or update > > Does the user actually care if it's a back- or forwardport? I'd say "not > really". Well, I can't image a situation where I would like to do both back- and forward-port so lets merge them. > > - special cases like kde-redhat - 2 repos (again stable + > > testing) per case, stable enabled by default > > Rex, would you actually need "stable" and "testing" repos or could this > work without "testing"? > > > Does this sound feasible? > > As I said, not sure yet. I'll think about it for a while longer ;-) It is a view of my situation, a view how to utilize existing infrastructure to bring more value for the users. And I expect that there are other packagers in similar situation. Dan
Re: Where we are and where do we what to go?
Thorsten Leemhuis píše v Út 10. 02. 2009 v 10:14 +0100: > On 10.02.2009 09:57, Dan Horák wrote: > > Thorsten Leemhuis píše v Po 09. 02. 2009 v 19:58 +0100: > >> On 09.02.2009 14:28, Dan Horák wrote: > >>> Thorsten Leemhuis píše v Ne 08. 02. 2009 v 10:06 +0100: > >>>> On 04.02.2009 14:24, Rex Dieter wrote: > >>>>> Thorsten Leemhuis wrote: > >>>>>> On 04.02.2009 14:00, Rex Dieter wrote: > >>>>>>> Andrea Musuruane wrote: > >>>>>>> [...] > >>>>>>> In the meantime, I'll go adjust the wiki to move kde-redhat to the > >>>>>>> "compatible" section. :) > >>>>>> If RPM Fusion would have one big and/or multiple dedicated > >>>>>> experimental > >>>>>> repos, would kde-redhat then be interested into "merging" into RPM > >>>>>> Fusion? > >>>>> yes! > >>>> I'd like that to happen. What others think of the idea to start a > >>>> experimental area and do the first steps with kde-redhat like repos? > >>> I agree and would like join with some of my stuff. > >> Hmmm. kde-redhat is something special, so a dedicated repo for it makes > >> a lot of sense afaics. > >> But do you need to have your own dedicated experimental repo. Might a > >> general experimental repo be a better solution? Not sure myself, just > >> want to hear options... > > > > Oh, I was thinking that we are going to offer a merger for the personal > > or highly specialized repos into one experimental repo (if possible) > > that will use RPM Fusion's infrastructure. > > [...] > > When there should be multiple repos, then I would prefer to divide them > > by relation to Fedora/RPM Fusion (eg. experimental, backports) rather > > then by area (kde, mono, math, ...) > > A dedicated "math" repo like really is not needed -- those packages are > likely more suitable for a general experimental and/or staging repo. But > I guess some sort of spits by area will be needed -- I guess that (for > example) the kde-redhat users likely don't want to get highly > experimental graphics drivers from the same repo when they run yum-update. > > Or how would you solve that? Excludes and includepkgs statements in the > repo files are likely way to complicated... I should have known it will be complicated, but let's try to categorize the possible stuff: - new packages => no conflicts with Fedora/RPM Fusion => 2 repos (stable + testing), stable enabled by default - existing packages - experimental - examples: codeblocks - backports - examples: - forwardports (new stable versions from Fedora into EL) - examples: zabbix (no rebase 1.4->1.6 planned due DB changes etc, but some users would appreciate to have the 1.6) - one repo for each category, disabled by default, user must manually enable the repo and pick the package he want to install or update - special cases like kde-redhat - 2 repos (again stable + testing) per case, stable enabled by default Does this sound feasible? Dan
Re: Where we are and where do we what to go?
Thorsten Leemhuis píše v Po 09. 02. 2009 v 19:58 +0100: > On 09.02.2009 14:28, Dan Horák wrote: > > Thorsten Leemhuis píše v Ne 08. 02. 2009 v 10:06 +0100: > >> On 04.02.2009 14:24, Rex Dieter wrote: > >>> Thorsten Leemhuis wrote: > >>>> On 04.02.2009 14:00, Rex Dieter wrote: > >>>>> Andrea Musuruane wrote: > >>>>> [...] > >>>>> In the meantime, I'll go adjust the wiki to move kde-redhat to the > >>>>> "compatible" section. :) > >>>> If RPM Fusion would have one big and/or multiple dedicated experimental > >>>> repos, would kde-redhat then be interested into "merging" into RPM > >>>> Fusion? > >>> yes! > >> I'd like that to happen. What others think of the idea to start a > >> experimental area and do the first steps with kde-redhat like repos? > > > > I agree and would like join with some of my stuff. > > Hmmm. kde-redhat is something special, so a dedicated repo for it makes > a lot of sense afaics. > > But do you need to have your own dedicated experimental repo. Might a > general experimental repo be a better solution? Not sure myself, just > want to hear options... Oh, I was thinking that we are going to offer a merger for the personal or highly specialized repos into one experimental repo (if possible) that will use RPM Fusion's infrastructure. > > > But the question is what should be the relation between new repo and > > RPMFusion > > BTW: It's "RPM Fusion" (with space) ;-) I wasn't sure and looks like I forgot to make at least the spell checker happy :-) > > and Fedora > > 1. can contain packages that are already in RPMFusion/Fedora? > > and when 1 = yes then > > Yes. Otherwise merging kde-redhat afaics wouldn't make much sense > > > 2. can include packages newer then rawhide? > > I'd say so. (As long term gnome user) I'm not familiar at all with > kde-redhat, but I think that's what they also do now and then (like > preparing kde 4.2 before it hit rawhide or 4.1 before it hit F9?) > > > 3. can contain backports of rawhide packages to stable releases? > > I'd say so. > > In general: I wouldn't want to many rules for those repos. But we need > to be very careful. Having to many of those repos could be dangerous > (for us), confusing (for the users) and time consuming (for infra and > the people that take care of the infra). And we of course need to make > sure that the main repo remains the repo that normally offers everything > ordinary users want. When there should be multiple repos, then I would prefer to divide them by relation to Fedora/RPM Fusion (eg. experimental, backports) rather then by area (kde, mono, math, ...) Dan
Re: Where we are and where do we what to go?
Thorsten Leemhuis píše v Ne 08. 02. 2009 v 10:06 +0100: > On 04.02.2009 14:24, Rex Dieter wrote: > > Thorsten Leemhuis wrote: > >> On 04.02.2009 14:00, Rex Dieter wrote: > >>> Andrea Musuruane wrote: > >>> [...] > >>> In the meantime, I'll go adjust the wiki to move kde-redhat to the > >>> "compatible" section. :) > >> If RPM Fusion would have one big and/or multiple dedicated experimental > >> repos, would kde-redhat then be interested into "merging" into RPM > >> Fusion? > > yes! > > I'd like that to happen. What others think of the idea to start a > experimental area and do the first steps with kde-redhat like repos? I agree and would like join with some of my stuff. But the question is what should be the relation between new repo and RPMFusion and Fedora 1. can contain packages that are already in RPMFusion/Fedora? and when 1 = yes then 2. can include packages newer then rawhide? 3. can contain backports of rawhide packages to stable releases? Dan
Re: Where we are and where do we what to go?
Rex Dieter píše v St 04. 02. 2009 v 07:00 -0600: > Andrea Musuruane wrote: > > > I have placed known testing/staging repositories in a different section in : > > http://rpmfusion.org/FedoraThirdPartyRepos > > > > I have tracked most 3rd party maintainers/packagers too. > > > > We should have an agreed invite mail mail here: > > http://rpmfusion.org/InviteThirdPartyRepo > > > > So, what next? Who's gonna send this email to 3rd party > > maintainers/packagers? > > > Excellent work. I'd suggest a rpmfusion representative volunteer for > each repo, particularly someone who has some familiarity with the repo > or who runs it. I can take care of my own one :-) The content can be divided into 3 categories: 1 - packages not yet submitted for review, usually open for anyone to grab and submit 2 - experimental versions of Fedora/RPMFusion content 3 - backports of newer stuff to the Fedora release I am just using > > In the meantime, I'll go adjust the wiki to move kde-redhat to the > "compatible" section. :) dtto for my repo Dan
CA certificate for bugzilla.rpmfusion.org
Hi, where can be downloaded CA certificate for bugzilla.rpmfusion.org? My Galeon is complaining and wants a manual exception to be added, but that can't be done with one click, so I would prefer the real solution. Dan
Re: kino pulseaudio packaging dependency
Christopher Stone píše v Pá 31. 10. 2008 v 09:31 -0700: > On Fri, Oct 31, 2008 at 1:43 AM, Dan Horák <[EMAIL PROTECTED]> wrote: > > Christopher Stone píše v Pá 31. 10. 2008 v 01:33 -0700: > > I needed to remove pulseaudio after upgrading to rawhide the > other > > day, and in doing so I noticed that kino has a requirement > on > > pulseaudio. Should kino Requires be pulseaudio-libs > instead? > > > It must be an indirect dependency via esound. There are 3 > manual > Requires - audiofile, esound and ffmpeg. I will recheck the > need for the > first two, ffmpeg is used in the export scripts, so it must be > there. > > > This is what I get when yum runs a dependency check: > > --> Running transaction > check > ---> Package kino.x86_64 0:1.3.2-1.fc10 set to be > updated > --> Processing Dependency: esound for package: > kino > --> Running transaction > check > ---> Package pulseaudio-esound-compat.x86_64 0:0.9.13-4.fc10 set to be > updated > --> Processing Dependency: pulseaudio = 0.9.13-4.fc10 for package: > pulseaudio-esound-compat > --> Running transaction > check > ---> Package pulseaudio.x86_64 0:0.9.13-4.fc10 set to be > updated > --> Processing Dependency: pulseaudio-core-libs = 0.9.13-4.fc10 for > package: pulseaudio > --> Processing Dependency: libpulsecore.so.8()(64bit) for package: > pulseaudio > --> Running transaction check > ---> Package pulseaudio-core-libs.x86_64 0:0.9.13-4.fc10 set to be > updated > --> Finished Dependency Resolution > I could not find out why they are there (probably due some sound issues in the history), so I have removed them. But I have added new deps (mjpegtools and mencoder) for better AV format support in the import/export scripts. resulting rpms are now at http://buildsys.rpmfusion.org/plague-results/fedora-development-rpmfusion_free/kino/1.3.2-2.fc10/ Dan
Re: kino pulseaudio packaging dependency
Christopher Stone píše v Pá 31. 10. 2008 v 01:33 -0700: > I needed to remove pulseaudio after upgrading to rawhide the other > day, and in doing so I noticed that kino has a requirement on > pulseaudio. Should kino Requires be pulseaudio-libs instead? It must be an indirect dependency via esound. There are 3 manual Requires - audiofile, esound and ffmpeg. I will recheck the need for the first two, ffmpeg is used in the export scripts, so it must be there. Dan
Re: Call for help: mock configs for RPM Fusion
Thorsten Leemhuis píše v Út 02. 09. 2008 v 20:53 +0200:
> On 02.09.2008 20:38, Dan Horák wrote:
> > Thorsten Leemhuis píše v Út 02. 09. 2008 v 19:48 +0200:
> >> More and more people asked for mock configs files that they can use for
> >> test-building RPM Fusion packages. I don't have such files, but I
> >> uploaded the mock config files used on the builders to
> >>
> >> http://www.leemhuis.info/files/fedorarpms/MISC.rfu/mock/
> >>
> >> DON'T USE THEM! They need modifications before they are ready for
> >> normaly use!
> >>
> >> I'd thus appreciate it if someone with a few spare cycles could take
> >> them and update them (see below)(¹); we after that should create
> >> rpmfusion-mockcfgs-{non,}free packages(²); after reviewing those we can
> >> put them in our repos.
> >
> > I am not sure that creating a package with mock config is necessary,
>
> It IMHO is not necessary, but makes things a whole lot easier for
> everyone -- just like putting the repo files for yum into a foo-release
> package ;-)
>
> > a
> > page on the Wiki with the relevant sections for adding into users' mock
> > configs could be sufficient.
>
> I would never suggest that to people -- or -- that way lie dragons:
> quickly someone will test-build a package for review in Fedora and not
> notice that it requires something from RPM Fusion as dep. Rpmnewfile
> that uers need to manually merge is another bad side-affect.
>
Yes, creating whole new configs will be safer. And let's create
rpmfusion-mockconfig package. There should be no difference between
applying local changes into a new config and adding new repo into a copy
of current config. Only my workflow will be a bit different ;-)
Dan
Re: Call for help: mock configs for RPM Fusion
Thorsten Leemhuis píše v Út 02. 09. 2008 v 19:48 +0200:
> Hi!
>
> More and more people asked for mock configs files that they can use for
> test-building RPM Fusion packages. I don't have such files, but I
> uploaded the mock config files used on the builders to
>
> http://www.leemhuis.info/files/fedorarpms/MISC.rfu/mock/
>
> DON'T USE THEM! They need modifications before they are ready for
> normaly use!
>
> I'd thus appreciate it if someone with a few spare cycles could take
> them and update them (see below)(¹); we after that should create
> rpmfusion-mockcfgs-{non,}free packages(²); after reviewing those we can
> put them in our repos.
I am not sure that creating a package with mock config is necessary, a
page on the Wiki with the relevant sections for adding into users' mock
configs could be sufficient. And when we will decide to create such
package then the configs should be based on the official Fedora one,
only with rpmfusion sections added.
I have just successfully tested this section:
[rpmfusion-free]
name=rpmfusion-free
baseurl=http://download1.rpmfusion.org/free/fedora/development/x86_64/os/
added into my normal Fedora mock config, when build new package for
kino.
Dan
--
Fedora and Red Hat package maintainer
Re: RPM Fusion for EL/EPEL 5
Thorsten Leemhuis píše v Po 11. 08. 2008 v 19:09 +0200: > Hi all! > > More and more people talk to me and ask "when will RPM Fusion for > EL/EPEL 5 start". As a big junk of the livna import is now done I might > over the next few weeks slowly start to do the same work for EPEL. But I > need to know which of the package owners actually is willing to maintain > their packages in RPM Fusion's EL-branch. > > So if you want to maintain all or some of you packages for EL drop me a > line please. Then I'll create branches for them sooner or later and help > with the initial build round just like I do for Fedora now. > I am ready push kino into the EL-branches (EL4 + EL5), prerequisites are ffmpeg and libquicktime. > You are a Fedora/EPEL packager and interested in RPM Fusion for EL/EPEL > as well but don't own packages in RPM Fusion (or dribble / frehsrpms / > livna) yet? Then drop me a line -- some of the current RPM Fusion > packagers won't be intersted in EPEL, so we need to find owners for > their packages in RPM Fusions EL-branch. There are likely some deps for > RPM Fusions packages that are still missing in EPEL -- so the more hands > that can help with that the better. Dan
Re: Notification: Dribbles CVSsync done
Julian Sikorski píše v Út 03. 06. 2008 v 13:06 +0200: > Xavier Lamien pisze: > > Hello folks, > > > > All dribbles packages are now branched into cvs repository with > > following branches : F-8, F-9 & EL-5 > > > > Regards, > > -- > > Xavier.t Lamien > > -- > > http://fedoraproject.org/wiki/XavierLamien > > GPG-Key ID: F3903DEB > > Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB > > Here is what I am getting upon an import attempt: > [EMAIL PROTECTED] sdlmame-data]$ LANG=C ./common/cvs-import.sh > /home/jsikorski/rpmbuild/SRPMS/sdlmame-data-0125-1.fc8.src.rpm -m > "Initial import" > Checking out module: 'sdlmame-data' > Unpacking source package: sdlmame-data-0125-1.fc8.src.rpm... > L Mameinfo0125.zip > L catveren.zip > L cheat117.zip > L mamehistory125.zip > L sdlmame-ctrlr.tgz > A sdlmame-data.spec > error: Macro %dist has empty body > error: Macro %dist has empty body > error: Macro % has illegal name (%define) > error: Macro % has illegal name (%define) > error: Macro %dist has empty body > error: Macro %dist has empty body > error: Macro % has illegal name (%define) > error: Macro % has illegal name (%define) > error: Macro %dist has empty body > error: Macro %dist has empty body > error: Macro % has illegal name (%define) > error: Macro % has illegal name (%define) > error: Macro %dist has empty body > error: Macro %dist has empty body > error: Macro % has illegal name (%define) > error: Macro % has illegal name (%define) > error: Macro %dist has empty body > error: Macro %dist has empty body > error: Macro % has illegal name (%define) > error: Macro % has illegal name (%define) > error: Macro %dist has empty body > error: Macro %dist has empty body > error: Macro % has illegal name (%define) > error: Macro % has illegal name (%define) > error: Macro %dist has empty body > error: Macro %dist has empty body > error: Macro % has illegal name (%define) > error: Macro % has illegal name (%define) > error: Macro %dist has empty body > error: Macro %dist has empty body > error: Macro % has illegal name (%define) > error: Macro % has illegal name (%define) > These errors look like a missing "branch" file. Dan
sponsor needed
Hi, few months ago we spoke that I will become new Kino maintainer after Dominik. The rpmfusion infrastructure is coming near, so I have created an account at rpmfusion's fas and now I am waiting for a sponsor. The account name is "sharkcz", the same as in Fedora. Thanks Dan -- Fedora and Red Hat package maintainer
Re: Orphaned Packages from Dribble
Hans de Goede píše v So 26. 04. 2008 v 12:33 +0200: > Patrice Dumas wrote: > > On Sat, Apr 26, 2008 at 12:12:46PM +0200, Andrea Musuruane wrote: > >> I'd be happy to but I'm going on holiday tomorrow. I'll be back on May > >> 4th. If no-one else has already picked it up I'll do my duty :) > > > > I had a look and it seems to have already been reviewed... > > > > Yes Dan, has been so kind to review all 3 of them, and quite quick too, > thanks Dan! I was in a reviewing mood this week ;-) But could someone take a look at https://bugzilla.redhat.com/show_bug.cgi?id=442280 ? Dan
