ffmpeg-4.x compat package

[Hans de Goede]

Hi All,

I was wondering if there are any plans to provide a ffmpeg-4.x compat
package given that 5.0 has seen a signficant API break?

The reason is that I have been looking into updating vice and
it will not build in rawhide due to the new ffmpeg.

I filed a bug against vice upstream for this and they suggested
using ffmpeg-4.x for now since 5.0 is a big API break, see:

https://sourceforge.net/p/vice-emu/bugs/1697/

The vice ffmpeg functionality (video recording) is optional so
I'm going to disable it in rawhide for now.

Regards,

Hans

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

Re: F34 Nonfree: Fail to build from source list.

[Hans de Goede]

Hi,

On 2/4/21 5:12 PM, Leigh Scott wrote:
> caja-dropbox
> d1x

I'm working on fixing d1x now.

> dream
> frobtads

And I will also take care of frobtads.

Regards,

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

Re: F33 FTBFS list

[Hans de Goede]

Hi,

On 8/19/20 2:06 PM, Leigh Scott wrote:

free FTBFS

ProjectX
deepin-movie
deepin-screen-recorder
deepin-voice-recorder
dosemu
freeguide
game-data-packager
kodi-inputstream-adaptive
kodi-peripheral-joystick
kodi-pvr-dvblink
kodi-pvr-demo
kodi-pvr-dvbviewer
kodi-pvr-iptvsimple
kodi-pvr-mediaportal-tvserver
kodi-pvr-hts
kodi-pvr-mythtv
kodi-pvr-njoy
kodi-pvr-nextpvr
kodi-pvr-vbox
kodi-pvr-wmc
kodi-pvr-vuplus
kodi-pvr-vdr-vnsi
kodi-visualization-spectrum
libopenshot
libtgvoip
mlt-freeworld
mythtv
openmw
pithos
ppsspp
telegram-desktop
tvheadend
vcmi
vlmc


nonfree FTBFS

dream
megasync
pipelight
vice


I will take care of vice (I'll also rebase it to a newer upstream version while 
at it).

Regards,

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

Re: f32-free ftbfs list

[Hans de Goede]

Hi,

On 3/10/20 4:24 PM, Leigh Scott wrote:


On 10/03/2020 15:15, Hans de Goede wrote:

But SheepShaver and xroar are free, so they should be
on the list?



They are both listed


Sorry my bad, I got confused by the selective quoting further
down the thread.

Regards,

Hans




 > SheepShaver
 > VirtualBox
 > amule
 > aqualung
 > audacity-freeworld
 > chromium-browser-privacy
 > chromium-freeworld
 > comskip
 > deadbeef
 > fakenes
 > fs-uae
 > game-data-packager
 > gcube
 > girl
 > gstreamer-ffmpeg
 > kodi
 > libopenshot
 > libva-intel-driver
 > lives
 > mate-applet-streamer
 > medialibrary
 > minidlna
 > motion
 > mp3splt-gtk
 > obs-studio
 > openmw
 > openshot
 > performous
 > phonon-backend-vlc
 > ppsspp
 > python-vlc
 > qt5-qtwebengine-freeworld
 > stella
 > swftools
 > tvheadend
 > vokoscreen
 > xine-lib
 > xroar
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

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

Re: f32-free ftbfs list

[Hans de Goede]

Hi,

On 3/10/20 4:12 PM, Hans de Goede wrote:

Hi,

On 3/10/20 5:06 AM, Sérgio Basto wrote:

On Wed, 2020-02-05 at 19:15 +0300, Vascom wrote:

May be create google docs sheet as at last massrebuild?


I like the idea , just found the stella still FTBFS ...


I was about to reply that I've looking into this on my TODO
list, but I see that you have already taken care of this,
thank you.

I see you've build this for rawhide/f33 now, we should
really also kick of a build for f32, is there any reason why
you have not done this?


ср, 5 февр. 2020 г., 19:12 Leigh Scott :

And

zsnes


Hmm I have a couple of others on the list which I made
myself based on the buildsys notification emails during
the mass-rebuild:

SheepShaver, d1x, xroar, frobtads

These seem to be missing from your list ?


Ah wait, this was the free repo list and
d1x and frobtads are nonfree.

But SheepShaver and xroar are free, so they should be
on the list?

Regards,

Hans

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

Re: f32-free ftbfs list

[Hans de Goede]

Hi,

On 3/10/20 5:06 AM, Sérgio Basto wrote:

On Wed, 2020-02-05 at 19:15 +0300, Vascom wrote:

May be create google docs sheet as at last massrebuild?


I like the idea , just found the stella still FTBFS ...


I was about to reply that I've looking into this on my TODO
list, but I see that you have already taken care of this,
thank you.

I see you've build this for rawhide/f33 now, we should
really also kick of a build for f32, is there any reason why
you have not done this?


ср, 5 февр. 2020 г., 19:12 Leigh Scott :

And

zsnes


Hmm I have a couple of others on the list which I made
myself based on the buildsys notification emails during
the mass-rebuild:

SheepShaver, d1x, xroar, frobtads

These seem to be missing from your list ?

I plan to look into these soonish; and I also have zsnes on
my list of FTBFS issues to look into.

Regards,

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

Re: nonfree devel packages not signed?

[Hans de Goede]

Hi,

On 19-08-19 22:20, Nicolas Chauvet wrote:

Le lun. 19 août 2019 à 22:10, Hans de Goede  a écrit :


Hi,

On 19-08-19 21:30, Nicolas Chauvet wrote:

Le lun. 19 août 2019 à 21:15, Hans de Goede  a écrit :


Hi All,

When I try to do an update on a rawhide/F31 install I get:

Package d2x-1.43-22.rebirth_v0.60.20181218gitaf25483.fc31.x86_64.rpm is not 
signed
Package doom-shareware-1.9-17.s.fc31.noarch.rpm is not signed
Package faac-1.29.9.2-7.fc31.x86_64.rpm is not signed
Package fdk-aac-2.0.0-3.fc31.x86_64.rpm is not signed
Package gstreamer1-plugins-bad-nonfree-1.16.0-2.fc31.x86_64.rpm is not signed
Package lha-1.14i-35.20161015git6f6cbc1.fc31.x86_64.rpm is not signed
Package libunrar-5.7.4-2.fc31.x86_64.rpm is not signed
Package mac-libs-4.11-8.u4b5.fc31.x86_64.rpm is not signed
Package pyskool-1.2.1-5.fc31.noarch.rpm is not signed
Package roadfighter-1.0.1269-16.fc31.x86_64.rpm is not signed
Package spear-demo-1-11.fc31.noarch.rpm is not signed
Package steam-1.0.0.61-3.fc31.i686.rpm is not signed
Package unrar-5.7.4-2.fc31.x86_64.rpm is not signed
Package vice-3.2-5.fc31.x86_64.rpm is not signed
Package vice-common-3.2-5.fc31.x86_64.rpm is not signed
Package vice-data-3.2-5.fc31.noarch.rpm is not signed
Package vice-x128-3.2-5.fc31.x86_64.rpm is not signed
Package vice-x64-3.2-5.fc31.x86_64.rpm is not signed
Package vice-xcbm-ii-3.2-5.fc31.x86_64.rpm is not signed
Package vice-xplus4-3.2-5.fc31.x86_64.rpm is not signed
Package vice-xvic-3.2-5.fc31.x86_64.rpm is not signed
Package wolf3d-shareware-1.4-10.fc31.noarch.rpm is not signed

And a few more.

The devel packages for free do seem to be signed ?


It's weird as packages shouldn't end unsigned in our repos (or the
repo itslef will fails to generate)
It could be that the yum.conf is pointing to the wrong key ?


I had that issue with the rawhide Fedora repo, now that that
is being signed with the f32 key, the errors are different then
if dnf misses the pub key it states so and it prints the pub key
the repo config points to. AFAICT this error really means the packages
are not signed.

So after poking around a bit and after updating
rpmfusion-[non]free-release* to get the new key, things work fine now,
even if I switch back to the -rawhide repos I was using before
weird.

One more remark, /etc/yum.repos.d/rpmfusion-[non]free-rawhide.repo
ship with gpgcheck=0 by default, but as my testing has just verified
the packages there are signed, so maybe we should change that to
gpgcheck=1 instead, as we do for the other repos?


We could turn gpgcheck=1 for rawhide indeed
(Now I would try to avoid to think about why it failed with gpg having
gpgcheck=0).


It failed for me with the "not signed" errors because I replaced the
gpgcheck=0 with gpgcheck=1 manually, sorry that I forgot to mention that
(I edited the mail several times as I was experimenting and got thing to
work and I ended up deleting the part where I said I had changed it to 1).

Regards,

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

Re: RPMFusion: F31 FTBFS

[Hans de Goede]

Hi,

On 8/11/19 3:54 PM, Nicolas Chauvet wrote:

Le dim. 11 août 2019 à 14:09, Sérgio Basto  a écrit :


Hi,
Here is the list of failed builds from last mass rebuild that is not
fixed yet.

12079   dream-2.1.1-7.fc31 (we have new version 2.2)
12054   xvst-3.0-6.20171201git14dee45.fc31
11989   mythtv-30.0-9.20190601git6bd8cd4993.fc31
11915   gr-dab-0.3-4.fc31
12138   ufoai-2.4-9.fc31

ufoai have to be retired as it's still missing the ufoai-data anyway
(that is too large for us to package this way, sorry about that).


12008   qt5-qtwebengine-freeworld-5.12.4-3.fc31
11878   bubbros-1.6.2-9.fc31 >

Seems like a pretty short list, but this makes me wonder if there are
maintainers dedicated to all of theses ? (and if the maintainers in
pkgdb are accurately listed).


I maintain bubbros, it needs to be ported to Python 3, I would like to
keep it alive, so I hope to find some time to port it, but no promises.

For F31 we may be able to get it to work with the Python 2 remnants
which will still be in F31, but for F32 it needs to be ported to Python 3
or dropped.

Regards,

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

rawhide buildroots broken

[Hans de Goede]

Hi All,

I've tried to build a new version of vice, but it is failing due to
the rawhide buildroots being broken.

If someone can take a look at this, that would be great.

Regards,

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

Re: VirtualBox back to testing in f28

[Hans de Goede]

Hi,

On 24-04-18 17:59, Sérgio Basto wrote:

On Tue, 2018-04-24 at 17:51 +0200, Nicolas Chauvet wrote:

Hi

FYI, Virtualbox is broken in f28 I will remove it from any stable
repo
(GA and updates) and leave it in updates-testing until someone
unbreak
it: We are not supposed to replace any fedora packages.

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4880#c3
https://bugzilla.redhat.com/show_bug.cgi?id=1481630#c74


did you read comment #72

you need a modified version of vboxsf to work with the upstream-kernel
version of the vboxguest module. This modified version is available
here:
https://github.com/jwrdegoede/vboxsf/


Right unfortunately the vboxsf version for the upstream kernel
is stuck in review (waiting for someone to make time to review it)
and I cannot backport it to the Fedora kernel until it is
accepted upstream (the Fedora kernel team does not want non
upstream code backported).

This is a good reason to keep akmod-virtualbox alive for F28,
but with my vboxsf code from above (which is intended for and
works with the upstream kernel) instead of virtualbox's own
vboxsf code which will not work with the upstream vboxguest
driver. This sucks, but it is what it is.

This is NOT a good reason to keep the virtualbox-guest-additions
package alive. There is no reason to have that in rpmfusion
anymore and as Nicolas said we have a clear policy that
rpmfusion will never replace Fedora pkgs.

Regards,

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

Re: gstreamer maintainer needed for freeworld packages

[Hans de Goede]

Hi,

On 15-03-18 17:56, Nicolas Chauvet wrote:

2018-03-01 11:13 GMT+01:00 Hans de Goede <j.w.r.dego...@gmail.com>:

Hi,

On 28-02-18 18:40, Nicolas Chauvet wrote:


Hi there,

There is a need to find a new maintainer(s) for the gstreamer packages
provided by us.
Leigh  indicated that he's not willing to work on them anymore for a
reason of its own.

Please respond to this thread and/or ask for ACL on pkgdb:
https://admin.rpmfusion.org/pkgdb/packages/gstreamer%2A/

Right now there is a need to update to 1.13 in rawhide/f28, but there
is a delay since theses packages aren't published yet (fedora infra
has repository compose issue for branched/rawhide).
There will be a need to adapt the split between plugin that have moved
to fedora proper. So this need to be carefully tested.

Thx for your help in this area. And please forward the request
everywhere relevant.


PS: If there is no volunteer by Fedora 28 Beta release, I'm afraid
that those packages will be removed from our repo.



If no one steps up I can start maintaining these again, the main reason
I stopped doing so is because Leigh was doing a good job at maintaining
these.


Hi Hans, Rex,

Thx for volunteering to maintain gstreamer in RPM Fusion, you are
still welcomed to do so for the coming gstreamer-1.13.91 release.
That been said, as I know you might be busy contributors. I will
re-send an invite for any other packager to maintain gstreamer in RPM
Fusion.


Yes ideally (from my pov) these would find a new maintainer with less
on his/her plate. Anyways if you (or Rex) ever need some help with this
please drop me a mail (at my gmail address please), these packages are
too important to go unmaintained.

Regards,

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

Re: gstreamer maintainer needed for freeworld packages

[Hans de Goede]

Hi,

On 28-02-18 18:40, Nicolas Chauvet wrote:

Hi there,

There is a need to find a new maintainer(s) for the gstreamer packages
provided by us.
Leigh  indicated that he's not willing to work on them anymore for a
reason of its own.

Please respond to this thread and/or ask for ACL on pkgdb:
https://admin.rpmfusion.org/pkgdb/packages/gstreamer%2A/

Right now there is a need to update to 1.13 in rawhide/f28, but there
is a delay since theses packages aren't published yet (fedora infra
has repository compose issue for branched/rawhide).
There will be a need to adapt the split between plugin that have moved
to fedora proper. So this need to be carefully tested.

Thx for your help in this area. And please forward the request
everywhere relevant.


PS: If there is no volunteer by Fedora 28 Beta release, I'm afraid
that those packages will be removed from our repo.


If no one steps up I can start maintaining these again, the main reason
I stopped doing so is because Leigh was doing a good job at maintaining
these.

Regards,

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

Re: FTBFS for f27

[Hans de Goede]

Hi,

On 19-09-17 04:50, Sérgio Basto wrote:

On Mon, 2017-09-04 at 16:00 +0200, Nicolas Chauvet wrote:

Here is a list of packages without a f27 tag currently in rawhide:
It's pretty much possible that the package fails at the
buildSRPMFromSCM step, in which case it's only a matter to resubmit.
I will handle the npapi-vlc.

Free:
./m/mixxx-2.0.0-9.fc26.src.rpm
./m/miam-player-0.8.1-0.12git1a21b01.fc26.src.rpm
./x/xine-plugin-1.0.2-12.fc26.src.rpm
./x/xine-ui-0.99.9-4.fc26.src.rpm
./s/sonic-visualiser-freeworld-2.4.1-1.fc25.src.rpm
./s/sox-plugins-freeworld-14.4.2-1.fc25.src.rpm
./v/vdr-plex-0.4.0-3.fc26.src.rpm
./b/BasiliskII-1.0-0.20160322.6.fc26.1.src.rpm


I've taken care of BasiliskII, it has been build for f27 and
rawhide now.

Regards,

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

Re: Working on RetroArch and libretro cores

[Hans de Goede]

Hi,

On 27-06-17 09:13, David Demelier wrote:

Le 27/06/2017 à 08:53, Hans de Goede a écrit :

Isn't retroarch itself available under a FOSS license ? If that is true
then retroarch itself (as well as any FOSS cores like MAME) should really
be packaged for Fedora proper, with only the non-free cores like snes9x
going to rpmfusion.



As fedora guidelines forbid anything regarding games emulators I expect the 
whole retroarch packages to be integrated in RPM Fusion instead of having some 
in fedora and some in RPM Fusion.


Fedora guidelines no longer out right forbid emulators:
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Emulators

"Emulators which depend on firmware or ROM files to function may not be included in 
Fedora, unless the copyright holder(s) for the firmware/ROM files give clear permission 
for the firmware/ROM files to be distributed (either under a Fedora permissible license 
or under the Fedora firmware exception criteria). Note: This only covers the situation 
where an emulator will not run at all without firmware/ROM files. For example, emulators 
that compile and run, but ship with no game ROMs are not covered by this rule."

So something like an msx emulator would be a problem as the msx needs
a boot ROM (*) but a NES emulator with a GUI to select a cartridge would
not be a problem.

*) In the case of the MSX there is a FOSS boot ROM solving this

Note that for example MAME is in normal Fedora too:

https://koji.fedoraproject.org/koji/packageinfo?packageID=22597


Otherwise, people will ask why RetroArch is in fedora and libretro cores not 
which is also not very convenient for the user.


Quite a few of the cores will be suitable for Fedora, since
retroarch provides a GUI AFAIK anything which is FOSS licensed
will be fine.

Also this is how we always do things put as much in possible in
Fedora, rpmfusion is only for packages which cannot go to Fedora.

Regards,

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

Re: Working on RetroArch and libretro cores

[Hans de Goede]

Hi,

On 27-06-17 08:48, demelier.da...@gmail.com wrote:

Hello all,

I'm currently porting RetroArch [0] and most of the common libretro [1]
cores for RPM Fusion.


Cool, as a former MAME contributor I'm glad to see this happen.


I'm quite new so there are still probably guideline or style issues and
such. However the packages build and run fine at the moment.

When I get more libretro cores ready I'll propose all of these packages
as review.

For the moment, if you have any feedback, or want to test, the .spec
files are located there:

 http://hg.markand.fr/rpms/

[0]: http://www.retroarch.com/
[1]: https://www.libretro.com/


Isn't retroarch itself available under a FOSS license ? If that is true
then retroarch itself (as well as any FOSS cores like MAME) should really
be packaged for Fedora proper, with only the non-free cores like snes9x
going to rpmfusion.

Regards,

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

Re: nVidia howto question or solution

[Hans de Goede]

Hi,

On 23-01-17 10:31, Leigh Scott wrote:

Maybe adding 'modprobe.blacklist=nouveau' to the kernel cmd options would help.


I believe the right magic is adding "rd.driver.blacklist=nouveau" to the kernel
commandline.

Regards,

Hans

p.s.

The reply-to for the list is wrong, it is set to 
"rpmfusion-develop...@rpmfusion.org"
which should be rpmfusion-developers@lists.rpmfusion.org, known issue ?
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

Re: Add DKMS support for nvidia packages.

[Hans de Goede]

Hi,

On 23-01-17 09:43, Leigh Scott wrote:

I would like to implement DKMS support for the nvidia driver.
Adding the support would add much to the work load and would offer users the 
choice of what they use.
The other benefit is I believe it will work better with offline updates as it 
builds during the transaction.


+1 from me, I see now problems with adding DKMS support as an option,

https://rpmfusion.org/Packaging/KernelModules/Kmods2#Why_not_simply_use_dkms

Even recommends offering it as an option.

Regards,

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

Re: Looking for new maintainer for the rpmfusion gstreamer* pkgs

[Hans de Goede]

Hi,

On 16-11-16 17:49, Sérgio Basto wrote:

On Qua, 2016-11-16 at 15:23 +0100, Hans de Goede wrote:

Hi,

On 16-11-16 15:15, Nicolas Chauvet wrote:


2016-11-13 12:26 GMT+01:00 Hans de Goede <j.w.r.dego...@gmail.com>:


Hi All,

My plate wrt opensource projects I maintain / work
on is getting a bit too full, so I'm trying to
delegate various tasks.

As such I'm looking for someone to take over the
rpmfusion gstreamer* pkgs from me. I welcome new
maintainers for any other rpmfusion pkgs I maintain
as well.

Thx for fixed the gstreamer packages.

Did you know anyone that could take over the maintenance of the
packages from any of your colleges ?
Specially is there anyone that would already maintain some
gstreamer
package is fedora and would do the related ones in RPM Fusion ?

Well, of course if there is no maintainer, the old rule apply: they
should be removed from the repo.
I would better have a maintainer than an exception here given how
important the package for some desktop.

If no-one steps up I will keep maintaining these, but since they
are used by so many people I hope someone else will show an
interest in maintaining them. So any takers ? I'm happy to
co-maintainen.


First sorry for my bad mood in the other day, It was more private
things than Fedora/RPMFusion things, so my sincerely apologizes,
sometimes I think is too much for me ... . And I appreciate much your
work .

I can maintain audacious-plugins-freeworld since is a package that I
use, so I can test it .


That is actually the one I use the most myself too :) Still if you
see an issue with it, feel free to fix it, I always welcome
co-maintainership, even if its just for the occasional fix.

Regards,

Hans

Re: Looking for new maintainer for the rpmfusion gstreamer* pkgs

[Hans de Goede]

Hi,

On 16-11-16 15:15, Nicolas Chauvet wrote:

2016-11-13 12:26 GMT+01:00 Hans de Goede <j.w.r.dego...@gmail.com>:

Hi All,

My plate wrt opensource projects I maintain / work
on is getting a bit too full, so I'm trying to
delegate various tasks.

As such I'm looking for someone to take over the
rpmfusion gstreamer* pkgs from me. I welcome new
maintainers for any other rpmfusion pkgs I maintain
as well.


Thx for fixed the gstreamer packages.

Did you know anyone that could take over the maintenance of the
packages from any of your colleges ?
Specially is there anyone that would already maintain some gstreamer
package is fedora and would do the related ones in RPM Fusion ?

Well, of course if there is no maintainer, the old rule apply: they
should be removed from the repo.
I would better have a maintainer than an exception here given how
important the package for some desktop.


If no-one steps up I will keep maintaining these, but since they
are used by so many people I hope someone else will show an
interest in maintaining them. So any takers ? I'm happy to
co-maintainen.

Regards,

Hans

Builds failing again due to buildroot issues

[Hans de Goede]

Hi,

Sorry to bring bad news again, but builds are failing
again due to buildroot issues on both f25 and rawhide.

Specificially populating the buildroot fails for building
the SRPM.

Regards,

Hans

Looking for new maintainer for the rpmfusion gstreamer* pkgs

[Hans de Goede]

Hi All,

My plate wrt opensource projects I maintain / work
on is getting a bit too full, so I'm trying to
delegate various tasks.

As such I'm looking for someone to take over the
rpmfusion gstreamer* pkgs from me. I welcome new
maintainers for any other rpmfusion pkgs I maintain
as well.

Regards,

Hans

Re: mpg123 is in Fedora 25+ now, should be dropped from rpmfusion

[Hans de Goede]

Hi,

On 13-11-16 11:33, Nicolas Chauvet wrote:

2016-11-13 10:54 GMT+01:00 Hans de Goede <j.w.r.dego...@gmail.com>:

Hi,

On 13-11-16 09:53, Andrea Musuruane wrote:


Hi Hans,
 you have to retire it (not to orphan it).

This procedure is up to date AFAIK:
http://rpmfusion.org/Contributors#Retiring_a_package

Bye,

Andrea



Thank you, I've added dead.package files to git and created:

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

I think you should be able to use pkgdb to retire the package.
Now I still wonder if we still need mpg123 in 25 GA repo. I think so,
so it won't break users that might install with kickstart and only GA
repos for both projects.


I went here (and logged in):

https://admin.rpmfusion.org/pkgdb/package/free/mpg123/

I can orphan it there, but I don't think I can retire it
there.

Regards,

Hans

Re: mpg123 is in Fedora 25+ now, should be dropped from rpmfusion

[Hans de Goede]

Hi,

On 13-11-16 09:53, Andrea Musuruane wrote:

Hi Hans,
 you have to retire it (not to orphan it).

This procedure is up to date AFAIK:
http://rpmfusion.org/Contributors#Retiring_a_package

Bye,

Andrea


Thank you, I've added dead.package files to git and created:

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

Regards,

Hans

Re: rpmfusion buildsystem network connectivity issues?

[Hans de Goede]

Hi,

On 13-11-16 10:08, Nicolas Chauvet wrote:

2016-11-13 9:39 GMT+01:00 Hans de Goede <j.w.r.dego...@gmail.com>:

Hi All,

It seems that the buildsystem is having network connectivity issues?

I see 3 problems:

1) If I do a git push, then it hangs in what I presume is a post-push hook,
if I then ctrl+c and do a git remote update then everything did get pushed

2) F25 builds have been failing for the last 2 days due to buildroot issues
(I was waiting for the cronjob to fix this, but it does not seem to)

3) The newrepo task for all repos seems to be failing, see:
http://koji.rpmfusion.org/koji/index


thx for reporting.
1/ is the forward to github script that has perm issue , fixing that.
2/3/ should be workaround now, it's about koji builder not cleaning
their createrepo_c tasks. I need to figure out why or implement a
better workaround.


Thank you, it seems there now is an issue with the rawhide-free buildroot
though ?

Regards,

Hans

rpmfusion buildsystem network connectivity issues?

[Hans de Goede]

Hi All,

It seems that the buildsystem is having network connectivity issues?

I see 3 problems:

1) If I do a git push, then it hangs in what I presume is a post-push hook,
if I then ctrl+c and do a git remote update then everything did get pushed

2) F25 builds have been failing for the last 2 days due to buildroot issues
(I was waiting for the cronjob to fix this, but it does not seem to)

3) The newrepo task for all repos seems to be failing, see:
http://koji.rpmfusion.org/koji/index

Regards,

Hans

mpg123 is in Fedora 25+ now, should be dropped from rpmfusion

[Hans de Goede]

Hi Nicolas,

$subject says it all, not sure what the orphan process
for rpmfusion is, hence this direct mail.

Regards,

Hans

Re: [ANNOUNCE] pkgdb is live at rpmfusion.org !

[Hans de Goede]

Hi,

On 17-10-16 15:24, Richard Shaw wrote:

Thanks Nicolas for all the hard work!


+1 Many many thanks to Nicolas for all his hardwork to make
rpmfusion great again!

Regards,

Hans

Re: About chromium packaging

[Hans de Goede]

Hi,

On 07-08-16 14:03, Kevin Kofler wrote:

Nicolas Chauvet wrote:

libffmpeg.so is not provided anymore in the approved fedora build.
So I think there is nothing much to replace, but instead to provide
the shared library as a complement.


If it's not build as a shared library, then it's statically linked and
cannot be replaced at all (without recompiling the entire Chromium). And
anyway, you are also going to run into issue 3 (the hardcoded codec lists)
if you don't recompile the whole Chromium.


 I don't understand why you keep repeating this. I'm sure we can
come-up with a patch to make the codec-lists a runtime configurable
thing, this is not rocket science.

Regards,

Hans

Re: avidemux and gcc6

[Hans de Goede]

Hi,

On 11-07-16 14:16, Dan Horák wrote:

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.


No worries, I'm working on building avidemux with your fix for f24,
for rawhide we need to wait for kwizart to come back online as that
requires a re-generation of the rawhide-repo to fix the currently
broken rawhide buildroot.

Note I've pushed the fix to master / rawhide, so all that is needed
there is to start a build once the rawhide buildroot is ok again.

Regards,

Hans

Re: RPM Fusion new infra

[Hans de Goede]

Hi,

On 07/10/2016 07:55 PM, Andrew Schultz wrote:

On 07/10/2016 09:00 AM, Andrea Musuruane wrote:

Now it seems builders have problems:
[andrea@panoramix zboy]$ rfpkg build
Building zboy-0.60-2.fc25 for rawhide-free
Created task: 7991
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=7991
Watching tasks (this may be safely interrupted)...
7991 build (rawhide-free,
/free/zboy:df3a2631ef5d9937684988694b9d250e6ad2ff2b): free
7991 build (rawhide-free,
/free/zboy:df3a2631ef5d9937684988694b9d250e6ad2ff2b): free -> open
(arm-builder03.scaleway.rpmfusion.net
)
  7992 buildSRPMFromSCM
(/free/zboy:df3a2631ef5d9937684988694b9d250e6ad2ff2b): free
  7992 buildSRPMFromSCM
(/free/zboy:df3a2631ef5d9937684988694b9d250e6ad2ff2b): free -> open
(arm-builder02.scaleway.rpmfusion.net
)
  7992 buildSRPMFromSCM
(/free/zboy:df3a2631ef5d9937684988694b9d250e6ad2ff2b): open
(arm-builder02.scaleway.rpmfusion.net
) -> FAILED:
BuildrootError: could not init mock buildroot, mock exited with status
30; see root.log for more information


"see root.log for more information"


  0 free  1 open  0 done  1 failed
7991 build (rawhide-free,
/free/zboy:df3a2631ef5d9937684988694b9d250e6ad2ff2b): open
(arm-builder03.scaleway.rpmfusion.net
) -> FAILED:
BuildrootError: could not init mock buildroot, mock exited with status
30; see root.log for more information


"see root.log for more information"


  0 free  0 open  0 done  2 failed

7991 build (rawhide-free,
/free/zboy:df3a2631ef5d9937684988694b9d250e6ad2ff2b) failed

Bye,

Andrea



 From http://koji.rpmfusion.org/koji/taskinfo?taskID=7991

click "buildSRPMFromSCM",
=> http://koji.rpmfusion.org/koji/taskinfo?taskID=7992

click "root.log"
=> https://koji.rpmfusion.org/kojifiles/work/tasks/7992/7992/root.log


As already explained this is caused by the rawhide repo being broken atm, you
should be able to build for f24 and f23.

Regards,

Hans

Re: Various pkgs missing from f24 repos

[Hans de Goede]

Hi,

On 07/10/2016 04:33 PM, Andrea Musuruane wrote:

On Mon, Jun 27, 2016 at 8:16 PM, Hans de Goede <j.w.r.dego...@gmail.com 
<mailto:j.w.r.dego...@gmail.com>> wrote:

Hi All,

First of all many thanks to all who have been involved in getting the f24
repos in place. They look great and all the important pkgs are there.

I accidentally found out that some not so important pkgs are missing
though when running dnf repoquery --extras on my main workstation
which has way too much stuff installed :)


I notice that the following packages are missing too:
Nestopia
dega-sdl
meka

What's the best way to add them? Should I rebuild them? (BTW, I have problems 
with building - see other mail).


Yes you should build them for f24, sorry I do not know a solution for the
build problem you're seeing now. Did you check the logs? What is the exact 
error ?

Regards,

Hans

Re: RPM Fusion new infra

[Hans de Goede]

Hi,

On 07/10/2016 01:47 PM, Andrea Musuruane wrote:

Hi,
I'm trying to import zboy.

I followed this guide:
http://rpmfusion.org/Contributors#Import_your_package

But I get:
[andrea@panoramix zboy]$ rfpkg import 
/home/andrea/rpmbuild/SRPMS/zboy-0.60-2.fc23.src.rpm
Could not execute import_srpm: (35, 'Peer reports failure of signature 
verification or key exchange.')

Can somebody please help?


rfpkg import also does a rfpkg new-sources with the source tarbal in the srpm, 
that is likely
were the error is coming from.

You likely need to run rpmfusion-packager-setup first, and/or maybe manually 
download
a client-side certificate from: https://fas.rpmfusion.org/accounts/  (not sure 
if
rpmfusion-packager-setup does this automatically like the fedora version does).

If you manually download the client side certificate make sure to save it as
~/.rpmfusion.cert

If you get this to work, please update the wiki if necessary.

Thanks & Regards,

Hans

Re: rfpkg build fixed, you can build on koji !

[Hans de Goede]

Hi,

On 04-07-16 22:01, Nicolas Chauvet wrote:

Hi,

rfpkg build has been fixed, it's now possible to submit build request
with rfpkg-1.23-4
http://koji.rpmfusion.org/koji/buildinfo?buildID=851

Please build your packages for f23 to f25 (devel),


Awesome!

Unfortunately it seems something is still wrong, I tried to build
vice and for f24 I got the following errors:

mock_output.log:

ERROR: Command failed. See logs for output.
 # /usr/sbin/groupadd -g 135 mockbuild

root.log:

DEBUG util.py:495:  Executing command: ['/usr/sbin/userdel', '-r', '-f', 'mockbuild'] with env 
{'TERM': 'vt100', 'SHELL': '/bin/bash', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 
'printf "\x1b]0;\x07"', 'HOME': '/builddir', 
'HOSTNAME': 'mock', 'LANG': 'en_US.UTF-8'} and shell False
DEBUG util.py:283:  Unsharing. Flags: 134217728
DEBUG util.py:417:  userdel: user 'mockbuild' does not exist
DEBUG util.py:542:  Child return code was: 6
DEBUG util.py:563:  child environment: None
DEBUG util.py:495:  Executing command: ['/usr/sbin/groupdel', 'mockbuild'] with env {'TERM': 'vt100', 
'SHELL': '/bin/bash', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf 
"\x1b]0;\x07"', 'HOME': '/builddir', 'HOSTNAME': 
'mock', 'LANG': 'en_US.UTF-8'} and shell False
DEBUG util.py:283:  Unsharing. Flags: 134217728
DEBUG util.py:417:  groupdel: group 'mockbuild' does not exist
DEBUG util.py:542:  Child return code was: 6
DEBUG util.py:563:  child environment: None
DEBUG util.py:495:  Executing command: ['/usr/sbin/groupadd', '-g', '135', 'mockbuild'] with env 
{'TERM': 'vt100', 'SHELL': '/bin/bash', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 
'printf "\x1b]0;\x07"', 'HOME': '/builddir', 
'HOSTNAME': 'mock', 'LANG': 'en_US.UTF-8'} and shell False
DEBUG util.py:283:  Unsharing. Flags: 134217728
DEBUG util.py:417:  groupadd: GID '135' already exists
DEBUG util.py:542:  Child return code was: 4

Rawhide builds get past this point, but then fail due to rfpkg missing.

Keep up the good work and many thanks for EVERYTHING you've done to
get this far.

Regards,

Hans

Re: Various pkgs missing from f24 repos

[Hans de Goede]

Hi,

On 28-06-16 13:19, Sérgio Basto wrote:

On Ter, 2016-06-28 at 12:43 +0200, Hans de Goede wrote:


On 28-06-16 03:52, Sérgio Basto wrote:


Hello !

On Seg, 2016-06-27 at 20:16 +0200, Hans de Goede wrote:


Hi All,

First of all many thanks to all who have been involved in getting
the
f24
repos in place. They look great and all the important pkgs are
there.

I accidentally found out that some not so important pkgs are
missing
though when running dnf repoquery --extras on my main workstation
which has way too much stuff installed :)

Doing this gives the following (incomplete list):

-For f24 free:
   -SheepShaver
   -vbam
   -madplay
   -mock-rpmfusion-free
   -wormsofprey
   -xmris
   -zsnes

-For f24 nonfree:
   -d1x
   -doom-shareware
   -unrar
   -mac
   -mock-rpmfusion-nonfree
   -roadfighter
   -smc-music
   -spear-demo
   -vice
   -wolf4sdl
   -xv

All of these do have builds for older Fedora releases in the new
koji, so the easiest fix likely is to simple tag these as
f24-free-updates / f24-nonfree-updates .


Yes, we have to review this , I also have a list ( of dnf list
extras )
...



There seem to be 2 underlying problems:

1) The f24 repo did not inherit any builds from previous releases
(assuming we want to keep the base f24 pkg set frozen we cannot
fix
  this now)

2) Some pkgs never got rebuild for f24, I've not checked all of
the
above, but for those which I've checked there are no failed f24
builds,
they were likely simply never rebuild.

As said for starters I think we should tag these into f24-free-
updates /
f24-nonfree-updates. Quite a few of the above (incomplete!) list
are
mine, so I will prepare f24 builds for them.

I've already prepared and pushed a vice update for this, but
rfpkg new-sources is failing for me, and as is already known
rfpkg build does not work yet.

At least at free repo , I got some reports  that is working ,
https://pkgs.rpmfusion.org/repo/pkgs/free/?C=M;O=D

Well it does not work for me, can you try to rfpkg clone nonfree/vice
and then spectool -g *.spec, verify the downloaded sources match
the md5 in the sources file, and do rfpkg new-sources (note there
are 4 sources in the sources file) and see if this works for you ?


http://koji.rpmfusion.org/koji/buildinfo?buildID=704
I had install rfpkg-1.23.2-1.fc24.noarch in my F23


Ok, I've removed rfpkg and installed that exact version


It is working in free repo , could you try add --nonfree , should set
rpkg namespace with nonfree , although I think it is an hack .


Does not work:

[hans@shalem master]$ rfpkg --nonfree new-sources *icons.tar.bz2 
vice-2.4.28.tar.gz
usage: rfpkg [-h] [--config CONFIG] [--dist DIST] [--module-name MODULE_NAME]
 [--user USER] [--password PASSWORD] [--runas RUNAS] [--path PATH]
 [--verbose] [--debug] [-q]
 
{help,build,chain-build,clean,clog,clone,co,copr-build,commit,ci,compile,container-build,container-build-setup,diff,gimmespec,gitbuildhash,giturl,import,install,lint,local,mockbuild,mock-config,new,new-sources,patch,prep,pull,push,scratch-build,sources,srpm,switch-branch,tag,unused-patches,upload,verify-files,verrel,retire,update}
 ...
rfpkg: error: unrecognized arguments: --nonfree

Which is exactly why I asked (and you did not answer) :


2) what cmdline you're using
3) if you've any local config tweaks ?


Regards,

Hans

Re: Various pkgs missing from f24 repos

[Hans de Goede]

On 28-06-16 03:52, Sérgio Basto wrote:

Hello !

On Seg, 2016-06-27 at 20:16 +0200, Hans de Goede wrote:

Hi All,

First of all many thanks to all who have been involved in getting the
f24
repos in place. They look great and all the important pkgs are there.

I accidentally found out that some not so important pkgs are missing
though when running dnf repoquery --extras on my main workstation
which has way too much stuff installed :)

Doing this gives the following (incomplete list):

-For f24 free:
   -SheepShaver
   -vbam
   -madplay
   -mock-rpmfusion-free
   -wormsofprey
   -xmris
   -zsnes

-For f24 nonfree:
   -d1x
   -doom-shareware
   -unrar
   -mac
   -mock-rpmfusion-nonfree
   -roadfighter
   -smc-music
   -spear-demo
   -vice
   -wolf4sdl
   -xv

All of these do have builds for older Fedora releases in the new
koji, so the easiest fix likely is to simple tag these as
f24-free-updates / f24-nonfree-updates .



Yes, we have to review this , I also have a list ( of dnf list extras )
...


There seem to be 2 underlying problems:

1) The f24 repo did not inherit any builds from previous releases
(assuming we want to keep the base f24 pkg set frozen we cannot fix
  this now)

2) Some pkgs never got rebuild for f24, I've not checked all of the
above, but for those which I've checked there are no failed f24
builds,
they were likely simply never rebuild.

As said for starters I think we should tag these into f24-free-
updates /
f24-nonfree-updates. Quite a few of the above (incomplete!) list are
mine, so I will prepare f24 builds for them.

I've already prepared and pushed a vice update for this, but
rfpkg new-sources is failing for me, and as is already known
rfpkg build does not work yet.


At least at free repo , I got some reports  that is working ,
https://pkgs.rpmfusion.org/repo/pkgs/free/?C=M;O=D


Well it does not work for me, can you try to rfpkg clone nonfree/vice
and then spectool -g *.spec, verify the downloaded sources match
the md5 in the sources file, and do rfpkg new-sources (note there
are 4 sources in the sources file) and see if this works for you ?

Related to this, downloading from the lookaside-cache does not work
either, e.g. for vice rfpkg srpm fails with the first source, which
is already in the look-a-side.

If you do get this work can you please let me know:

1) which version of rfpkg you're using exactly
2) what cmdline you're using
3) if you've any local config tweaks ?


ignatenkobrain ask to update mpg123 the source is already uploaded !?!
this is what ignatenkobrain propose https://github.com/ascot-repo/mpg12
3/blob/master/mpg123.spec

in attach what I propose


esound is obsolete, Fedora has actively been working on removing it,
so we should not re-introduce deps on it, from the mpg123.spec changelog:

- Drop obsolete esound and arts plugins from mpg123-plugins-extras

> , I lost my chat log with him ... in resume,

he removed  /sbin/alternatives since claims that we haven't any other
alternative and also remove other spec snippets , I don't know the
impact of that, so I leave that to maintainers ( you :D ) .


wrt alternatives, we had mpg321 in the past not sure if we still do,
wrt the rebase to a newer version this is being tracked here:

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

I've also left a comment there explaining why I'm in no hurry to do
the rebase (it contains a bunch of major changes).

Regards,

Hans

Various pkgs missing from f24 repos

[Hans de Goede]

Hi All,

First of all many thanks to all who have been involved in getting the f24
repos in place. They look great and all the important pkgs are there.

I accidentally found out that some not so important pkgs are missing
though when running dnf repoquery --extras on my main workstation
which has way too much stuff installed :)

Doing this gives the following (incomplete list):

-For f24 free:
  -SheepShaver
  -vbam
  -madplay
  -mock-rpmfusion-free
  -wormsofprey
  -xmris
  -zsnes

-For f24 nonfree:
  -d1x
  -doom-shareware
  -unrar
  -mac
  -mock-rpmfusion-nonfree
  -roadfighter
  -smc-music
  -spear-demo
  -vice
  -wolf4sdl
  -xv

All of these do have builds for older Fedora releases in the new
koji, so the easiest fix likely is to simple tag these as
f24-free-updates / f24-nonfree-updates .

There seem to be 2 underlying problems:

1) The f24 repo did not inherit any builds from previous releases
(assuming we want to keep the base f24 pkg set frozen we cannot fix
 this now)

2) Some pkgs never got rebuild for f24, I've not checked all of the
above, but for those which I've checked there are no failed f24 builds,
they were likely simply never rebuild.

As said for starters I think we should tag these into f24-free-updates /
f24-nonfree-updates. Quite a few of the above (incomplete!) list are
mine, so I will prepare f24 builds for them.

I've already prepared and pushed a vice update for this, but
rfpkg new-sources is failing for me, and as is already known
rfpkg build does not work yet.

Regards,

Hans

Where to push f23 rpmfusion pkg updates ?

[Hans de Goede]

Hi All,

I'm working on updating the gstreamer1* pkgs for f23 to 1.6.4,
should I push the resulting changes to pkgs.kwizart.net as before
(and send a mail to request a build), or should I send a github
pull-req as done for f24?

Regards,

Hans

Re: Not sure what license tag to use

[Hans de Goede]

Hi,

On 11-04-16 15:27, Miro Hrončok wrote:

On 11.4.2016 09:19, Hans de Goede wrote:

On 11-04-16 00:17, Miro Hrončok wrote:

Hi, given the following terms:

  * MAY be used for commercial applications
  * MAY be shared freely
  * MUST NOT be reverse engineered

What kind of license tag is supposed to be used? The ideas are:

  * Redistributable, no modification permitted
  * Redistributable


I would say one of the 2 above, depending on if modification
is permitted. Since this "may be shared freely" it is
not just distributalble, it is REdistributable, as most
things we ship typically are.


Ok, but what about the MUST NOT be reverse engineered thing?


That definitely makes it non free, but otherwise does not need
to be mentioned in the License tag.

Fedora proper uses: "Redistributable, no modification permitted"
for the intel wireless firmware which also comes with a
no reverse engineering clause.

Regards,

Hans

Re: Not sure what license tag to use

[Hans de Goede]

Hi,

On 11-04-16 00:17, Miro Hrončok wrote:

Hi, given the following terms:

  * MAY be used for commercial applications
  * MAY be shared freely
  * MUST NOT be reverse engineered

What kind of license tag is supposed to be used? The ideas are:

  * Redistributable, no modification permitted
  * Redistributable


I would say one of the 2 above, depending on if modification
is permitted. Since this "may be shared freely" it is
not just distributalble, it is REdistributable, as most
things we ship typically are.


  * Distributable


Regards,

Hans

Re: Self-introduction: Neal Gompa

[Hans de Goede]

Hi Neal,

On 25-01-16 00:22, Neal Gompa wrote:

Hello all,

I've been a part of the Fedora community for many years, and a user of
RPM Fusion and its predecessors for equally as long. As a long-time
Fedora contributor, I never really had a reason to jump into the RPM
Fusion fray until a friend of mine prodded me a bit to get something
he liked into Fedora, which is why I've submitted a review request for
nordlicht ( https://bugzilla.rpmfusion.org/show_bug.cgi?id=3954 ).

I hope to have a good time here and that I can become involved in RPM
Fusion as I have in Fedora and other communities I'm a part of.


Welcome! Do I understand correctly that you're not yet a Fedora
packager ? If so it is probably better to first get a package
in Fedora itself, via the sponsor process. We do have a separate
sponsor process for rpmfusion for people who only want to become
a rpmfusion packager, but we greatly prefer / encourage people to
become Fedora packagers first.

If you're a Fedora packager, then we grant you packager rights in
rpmfusion too without needing to go through a separate sponsor
process.

Regards,

Hans

Re: port of game-data-packager to Fedora

[Hans de Goede]

Hi,

On 09-01-16 21:57, Alexandre Detiste wrote:

I've just sponsored you in rpmfusion fas now, so you have all
the same rights as in Fedora now.


Ok thanks, will wait on CVSsync then


Yes that may take a while though due to the infra wip.

Regards,

Hans

Re: port of game-data-packager to Fedora

[Hans de Goede]

Hi,

On 03-01-16 22:15, Alexandre Detiste wrote:

I still believe that innoextract belongs in Fedora proper,
so a first step at getting g-d-p in rpmfusion would be
to get innoextract into Fedora, see:

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

I can act as a sponsor for you in Fedora. I believe this is the best
way to process because of 2 reasons:

1) rpmfusion currently is overhauling its infra, so getting any new
pkgs in atm is kinda hard
2) rpmfusion requires a sponsor process for non Fedora packages just
like the Fedora process, but once you're an official Fedora packager
you get the same rights in rpmfusion automatically


What was needed to make the "automatically" bit work ?


When I said "automatically" I meant that you do not need to go through
a separate sponsoring process or some such. Once your first pkg gets
imported an admin will add you to the packager group, so automatically
may not be the best term to describe this.


I've got the same userid, email, etc.. in both FAS systems
and that doesn't seems to happen.

I have now manually requested to join
"RPM Fusion Packagers CVS commits Group (user)"
& "RPM Fusion Bugs Group (user)".


I've just sponsored you in rpmfusion fas now, so you have all
the same rights as in Fedora now.

Regards,

Hans

Re: Dealing with new approved packages for rpmfusion

[Hans de Goede]

Hi,

On 30-12-15 05:01, Sérgio Basto wrote:

Hello,
On Ter, 2015-12-29 at 13:12 +0100, Hans de Goede wrote:

Hi all,

Looking at:

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


you have confused me, 33 is RF_CVSsync


Right, so 33 is the packages for which a CVS admin request was
done as described here:

http://rpmfusion.org/Contributors#Your_package_gets_approved

 and 4 is RF_ACCEPT (accept means

approved ) so [1] have more package already approved

[1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=4


4 is for all packages which got approved in the history of
rpmfusion, not just those which have a pending CVS-admin
request for creating the pkg in CVS / bugzilla.


There are quite a few new packages which are waiting
to have CVS / git repos created for them and for them
to be imported / added to the repos.

I know that with the new infra this process is currently
on hold, but we are getting quite a big backlog of these,
and I'm afraid that not dealing with these in a timely
manner will scare of new contributors. So I wonder if
it would be possible to have a temporary process to
be able to process these while we're migrating to the
new infra ?

Thanks & Regards,

Hans


This work of review packages and approve it , can be used by anyone so
is not waste of time (IMHO).


I'm not saying it is  =a waste of time, otherwise I would not
be participating in this myself :)  What I'm saying is that
it would be good to unfreeze the CVS admin process, and actually
add new pkgs, getting a pkg through review and then not having it
show up the repo is just going to frustrate (new) contributors,
and is not going to motivate them to contribute more, were as
actually having the pkg show up in the repo will motivate
people.

> And the more organized we are, less work

we have. So can we clean a bit [1] (all review requests) ?


[1] 
https://bugzilla.rpmfusion.org/buglist.cgi?product=Package%20Reviews=Review%20Request=---_id=8635


I think that going over this list, and asking for a status update
on all of them, maybe with a suggestion to do review swap would
be good to do. But IMHO we should first unfreeze then CVS-admin
process. Poking people to get to work on these only to have
things grind to a halt as soon as the review passes is not helpful.

Regards,

Hans

Dealing with new approved packages for rpmfusion

[Hans de Goede]

Hi all,

Looking at:

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

There are quite a few new packages which are waiting
to have CVS / git repos created for them and for them
to be imported / added to the repos.

I know that with the new infra this process is currently
on hold, but we are getting quite a big backlog of these,
and I'm afraid that not dealing with these in a timely
manner will scare of new contributors. So I wonder if
it would be possible to have a temporary process to
be able to process these while we're migrating to the
new infra ?

Thanks & Regards,

Hans

Re: Bug triage for f23

[Hans de Goede]

Hi,

On 21-11-15 13:40, Nicolas Chauvet wrote:

2015-11-19 12:59 GMT+01:00 Hans de Goede <j.w.r.dego...@gmail.com>:




rpmfusion-nonfree pipelight
rpmfusion-nonfree pipelight-common



The problem with pipelight is that it depends on
pipelight-selinux which was imported into Fedora,
but then later dropped as the rest of pipelight
ended up in rpmfusion. We should add a new
pipelight-selinux package to rpmfusion-nonfree
and import the latest src.rpm from:

http://koji.fedoraproject.org/koji/buildinfo?buildID=545078

To fix this, feel free to make me the maintainer
of pipelight-selinux (I'm a pipelight user).



I don't get in which direction the wind blows currently WRT selinux policy
packaging, but can't we have the pipelight-selinux merged back into
pipelight package ? (keeping the -selinux package might be optional since
obviously we are using selinux by default and even this package requires
-selinux by default).


Ok, I've updated pipelight to the latest upstream and merged the selinux
policy into the existing pipelight package as suggested.

I've pushed this to ssh://gitoli...@pkgs.kwizart.net/nonfree/rpms/pipelight.git
master, so if you start a build then this one should be resolved too.

Thanks & Regards,

Hans

Re: Bug triage for f23

[Hans de Goede]

Hi,

On 15-11-15 08:12, Sérgio Basto wrote:

On Sáb, 2015-11-14 at 16:34 +0100, Nicolas Chauvet wrote:

Hello,

I'm still trying to focus on rfpkg/distgit infra tasks. But there are
others tasks that can be worked on.
Many packages are not recent enought for f23 and might fail at
runtime for any reason.


Sorry something went wrong in previous emails, the final list is:
rpmfusion-free bombono-dvd
rpmfusion-free get-flash-videos
rpmfusion-free libopenshot
rpmfusion-free mixxx
rpmfusion-free nailer
rpmfusion-free oxine
rpmfusion-free python-libopenshot
rpmfusion-free qmmp-plugins-freeworld
rpmfusion-free smc


smc just needs a rebuild against the F-23 buildroot
for the new boost found there. I've tested this locally,
just rebuilding the current f22 spec should be enough
(it will get a new dist-tag to make it newer).


rpmfusion-free smc-music


This one just needs smc to be fixed.


rpmfusion-free sox-plugins-freeworld
rpmfusion-free xpra-codecs-freeworld
rpmfusion-free z-push-zarafa
rpmfusion-nonfree frogatto


frogatto just needs a rebuild against the F-23 buildroot
for the new boost found there. I've tested this locally,
just rebuilding the current f22 spec should be enough
(it will get a new dist-tag to make it newer).


rpmfusion-nonfree gmameui
rpmfusion-nonfree pdflib-lite-perl
rpmfusion-nonfree pipelight
rpmfusion-nonfree pipelight-common


The problem with pipelight is that it depends on
pipelight-selinux which was imported into Fedora,
but then later dropped as the rest of pipelight
ended up in rpmfusion. We should add a new
pipelight-selinux package to rpmfusion-nonfree
and import the latest src.rpm from:

http://koji.fedoraproject.org/koji/buildinfo?buildID=545078

To fix this, feel free to make me the maintainer
of pipelight-selinux (I'm a pipelight user).

Regards,

Hans

Re: port of game-data-packager to Fedora

[Hans de Goede]

Hi,

On 07-11-15 18:23, Alexandre Detiste wrote:

Le mercredi 4 novembre 2015, 13:01:51 Hans de Goede a écrit :

So for now I'll just use/suggest the innoextract package provided by upstream.


I do not think this is a good idea, we really want to do this properly.


Ok I'll start with this one, because:
- it's the most usefull utility of the two
- the most stable too
- I can just re-use existing specfile (I have already pinged upstream about 
this)

https://github.com/arx/ArxPackages/blob/master/innoextract/rpm/innoextract.spec


Ok, for those reading along this one is being reviewed here now:

https://bugzilla.redhat.com/show_bug.cgi?id=1279175


I've taken a quick look, packaging rhash should be easy, it comes
with Makefile-s which properly generate versioned .so libs with a
proper soname at all, and honor DESTDIR, so packaging it really is
not a big deal. And this will actually be a good exercise for showing
that you know the basics of rpm packaging, which is requires to
become a Fedora / rpmfusion packager.





As for htmlcxx it does not come with a buildsys at all, and:


Huh ? The one in Debian uses autoconf

https://sources.debian.net/src/htmlcxx/0.85-3.4/configure.ac

https://sources.debian.net/src/htmlcxx/0.85-3.4/debian/rules

So that's just a 2-lines build there; the remainder is for the manpage.

%:
dh $@ --with autoreconf



https://github.com/dhoerl/htmlcxx


That one seems to be something totally unrelated.


Ok my bad, if it uses autoconf and a straight-forward build, then by
all means do package it for Fedora.


So this is what in Fedora we call a copylib, and bundling those is ok,



esp. when upstream does not provide any sort of (API) versioning
what so ever.

... so this point doesn't apply.



So you can simply put a snapshot of this in the
same src.rpm as innoextract / lgogdownloader,
and use that directly.


lgogdownloader is the current _single_ reverse dependency for this in
Debian, still I'd prefer to do it properly.
There, this one is not maitained by the Games team for example;
it was packaged by someone else years before lgogdownloader even existed.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504222

So I'd prefer to keep it separate; this part will likely require less uploads;
only when GCC decide to break all C++ packages.


Ack, as said if it is a proper lib with autoconf packaging it separately
makes perfect sense.


I wouldn't fight over inclusion of this or G-D-P in Debian main,
so here also I won't either.

I already got 2 relevant answers here before posting to rpmfusion ML:

https://lists.fedoraproject.org/pipermail/games/2015-November/thread.html


Ok, forget my previous comment asking to put this in Fedora then, lets
just put these 2 in rpmfusion nonfree. I still believe that innoextract belongs
in Fedora proper, so a first step at getting g-d-p in rpmfusion would be
to get innoextract into Fedora, see:


Extra hint: InnoSetup (the packager) is free software, albeit windows-only.
https://github.com/jrsoftware/issrc/blob/master/license.txt

I'll do that; I'll send the mail to fedora-devel


I can act as a sponsor for you in Fedora. I believe this is the best
way to process because of 2 reasons:

1) rpmfusion currently is overhauling its infra, so getting any new
pkgs in atm is kinda hard
2) rpmfusion requires a sponsor process for non Fedora packages just
like the Fedora process, but once you're an official Fedora packager
you get the same rights in rpmfusion automatically

Note the list at:

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Looks much longer / more complicated then the process actually is a lot
of steps are very quick. The most work is finding a sponsor (done already :)
and getting a few initial packages reviewed by your sponsor (that would be me).


I'm already at the "koji build --scratch f23 
rpmbuild/SRPM/innoextract-1.5-1.fc23.src.rpm" step ;-)


Great :)

Regards,

Hans

Re: port of game-data-packager to Fedora

[Hans de Goede]

Hi,

On 20-11-15 01:09, Alexandre Detiste wrote:

Le jeudi 19 novembre 2015, 13:23:48 Hans de Goede a écrit :

[htmlcxx]


Ok my bad, if it uses autoconf and a straight-forward build, then by
all means do package it for Fedora.


Is it ok for Fedora that the current only reverse dependency is in RPMFusion ?


Yes that should be fine.

Regards,

Hans

Re: Introducing myself

[Hans de Goede]

Hi Stephen,

On 11-11-15 16:22, Stephen Herr wrote:

Hi everyone,

I'm new to contributing to RPMFusion. I am behind the package review
request for pianobar, a terminal Pandora client.

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

I'm not new to creating RPMs and am a member of the Fedora GIT Commit
Group, but I'm not sure if I need a sponsor in RPMFusion or not. I believe
I have completed all the pieces of the RPM submission process that I can at
the moment, so I'm just waiting for a reviewer to take a look.


Welcome! If you're a sponsored Fedora packager already there is no need
for sponsoring in rpmfusion, you "inherit" your Fedora rights here :)

Note that atm rpmfusion is moving from our old cvs + plague based
infra to a new infra which mirrors the Fedora infra more closely.

This means that atm we are not processing any new package requests,
we hope to be able to process new package requests in the near future
though, so do not let that hold you back.

Getting a review pretty much works the same as in Fedora, you should
not expect someone to just pop-up and review things for you, doing
review swaps works best to get a review in a reasonable time,

Regards,

Hans

Re: What is missing for f23 readyness ?

[Hans de Goede]

Hi,

On 08-11-15 16:34, Sérgio Basto wrote:

Hi,
On Dom, 2015-11-08 at 15:17 +0100, Hans de Goede wrote:

Hi,

On 07-11-15 18:20, Sérgio Basto wrote:

On Sáb, 2015-11-07 at 15:05 +, Sérgio Basto wrote:

On Sáb, 2015-11-07 at 08:12 -0600, Richard Shaw wrote:

On Sat, Nov 7, 2015 at 5:07 AM, Nicolas Chauvet <kwiz...@gmail.com>
wrote:
  There is a number of packages that need to be rebuilt as they
  wasn't updated for f23 "mass rebuilt" specially because of c++
  ABI changes. If someone can bring me a list I will submit them
  for rebuild next week.



I don't mind helping with this but what tool would I use to determine
which packages still need to be rebuilt?






  Also few packages and libraries was not updated to their
  latest upstream or matching their fedora counterpart (faac,
  audacity-freeworld, etc). I would like to have maintainers
  contact provenpackager (that have access to the git preview
  repo) so they can fetch the update of theses packages.

  Best would be to make a general review of missing updates.


I have scripts in my vm with F23 to determinate what we need rebuild ,
I'll try send the list this afternoon.

Also got some other information about package that are missing (not
enter) in F22 and F23 , because, I think, they won't build in new koji
system .


1- query all rpmfusion package and date it :
repoquery --archlist=i386,i686 
--disablerepo=rawhide,fedora\*,updates\*,peem-kde4-fedora,sergiomb-vboxfor23 -a --qf 
"%{buildtime:isodate} %{name}-%{version}-%{release}" > listall.txt

2 - all build times of package with tag fc23 are after 2015-10-24 , so no need 
to rebuild:
cat listall.txt | grep fc23 | sort -nr

3 - packages to rebuild (are the packages with fc22 tag):
cat listall.txt | grep fc22  | cut -b 21- | xargs repoquery --source | sort -u
after pipe  with perl -pe 's/-\d.*?-\d+(\..*)?\.fc\d+(\..*)?.src.rpm//' we got 
the list in attachment

4 - packages without fc22 or fc23 tag:
cat listall.txt | grep -vP "fc22|fc23"
Only ufoai-data-2.4-1 and ufoai-data-server-2.4-1  more  buildsys and
releases packages


Sergio, Thanks for generating the list (attached to Sergio's original mail) but 
I do not
think this is what Nicolas had in mind, AFAICT Nicolas only wants to rebuild 
packages
which must be rebuilt due to c++ ABI changes and keep the rest as is. So not 
rebuild
all packages which have not been rebuild yet.


Thanks but I thought that is to follow Fedora and it was all packages
[1], I ask that at the time.

Anyway, Nicolas mention an provenpackager, I don't mind take care of the
mass rebuild , just need some instructions and the OK from Nicolas.

Another topic, that I not take care, is the packages that need matching
their fedora counterpart , can someone list it ? , are they only all
freeworld packages ? or we have exceptions ?


I think that *freeworld is a good start, I do not know any exceptions from
the top of my head. If anyone knows of any exceptions please speak-up now.

Regards,

Hans

Re: What is missing for f23 readyness ?

[Hans de Goede]

Hi,

On 07-11-15 18:20, Sérgio Basto wrote:

On Sáb, 2015-11-07 at 15:05 +, Sérgio Basto wrote:

On Sáb, 2015-11-07 at 08:12 -0600, Richard Shaw wrote:

On Sat, Nov 7, 2015 at 5:07 AM, Nicolas Chauvet 
wrote:
 There is a number of packages that need to be rebuilt as they
 wasn't updated for f23 "mass rebuilt" specially because of c++
 ABI changes. If someone can bring me a list I will submit them
 for rebuild next week.



I don't mind helping with this but what tool would I use to determine
which packages still need to be rebuilt?






 Also few packages and libraries was not updated to their
 latest upstream or matching their fedora counterpart (faac,
 audacity-freeworld, etc). I would like to have maintainers
 contact provenpackager (that have access to the git preview
 repo) so they can fetch the update of theses packages.

 Best would be to make a general review of missing updates.


I have scripts in my vm with F23 to determinate what we need rebuild ,
I'll try send the list this afternoon.

Also got some other information about package that are missing (not
enter) in F22 and F23 , because, I think, they won't build in new koji
system .


1- query all rpmfusion package and date it :
repoquery --archlist=i386,i686 
--disablerepo=rawhide,fedora\*,updates\*,peem-kde4-fedora,sergiomb-vboxfor23 -a --qf 
"%{buildtime:isodate} %{name}-%{version}-%{release}" > listall.txt

2 - all build times of package with tag fc23 are after 2015-10-24 , so no need 
to rebuild:
cat listall.txt | grep fc23 | sort -nr

3 - packages to rebuild (are the packages with fc22 tag):
cat listall.txt | grep fc22  | cut -b 21- | xargs repoquery --source | sort -u
after pipe  with perl -pe 's/-\d.*?-\d+(\..*)?\.fc\d+(\..*)?.src.rpm//' we got 
the list in attachment

4 - packages without fc22 or fc23 tag:
cat listall.txt | grep -vP "fc22|fc23"
Only ufoai-data-2.4-1 and ufoai-data-server-2.4-1  more  buildsys and
releases packages


Segio, Thanks for generating the list (attached to Segio's original mail) but I 
do not
think this is what Nicolas had in mind, AFAICT Nicolas only wants to rebuild 
packages
which must be rebuilt due to c++ ABI changes and keep the rest as is. So not 
rebuild
all packages which have not been rebuild yet.

I do not have (much) time to work on this myself, but if there is anything 
specific
I can help with (ie specific FTBFS errors), let me know and I'll gladly help.

Regards,

Hans

Re: port of game-data-packager to Fedora

[Hans de Goede]

Hi,

On 03-11-15 17:07, Alexandre Detiste wrote:

Le mardi 3 novembre 2015, 14:49:47 Hans de Goede a écrit :



I'm now running it thourgh virtualbox, maintenance will be more bearable
when I manage to run it in a thin container with full X/OpenGl support.
(systemd-nspawn ?)


Ok, so you do plan to maintain it, that would be great as we
are currently having a shortage of active packagers for rpmfusion.


Yes I can maintain this one package.

I don't like the "summer of code" mindset of releasing something
half done & then disapear. I'm also interrested into Fedora
users contributing details of games(/versions) missing.


That is great!


The generated .rpm always go to ~/rpmbuild/RPMS/noarch/
where the default is $(pwd) on Debian; I didn't found a simple
way to overide this, but maybe that's not desired and
it's better to remove the "--destination" option.


You can pass:

--define "_rpmdir $(pwd)"

to rpmbuild to use the cwd as output dir, the rpms will then be written
to $(pwd/noarch I do not believe there is a way to get rid of the "noarch"
part of the path.


It's a bit ugly, but --define "_rpmdir /tmp" might be of use
if user want to install package right away without keeping the rpm.


Having a option not to compressing 2GB rpm's that'll be used locally
or rpm's that are zipfile + little else (like Quake .pk? archives) would
be nice too.


Erm, I'm pretty sure you can do that too, but I do not know how.


I found what I needed : "%define _binary_payload w0.gzdio"
&  "%define _binary_payload w1.gzdio" .


All scummvm & z_code games (Zork, H2G2) should already work as-is.

For the other games, the assets are located where the Debian-packaged
engines except those, thus mostly in /usr/share/games/

See "grep usr/share/games data/*.yaml".

So each engine needs to be reviewed.


Yeah, we typically put game-data under /usr/share/foo rather then
/usr/share/games/foo. But for things like scummvm you likely also
provide a .desktop for the game, passing in the right options to
start the game ?  Then using /usr/share/games should be fine.


Yes, indeed when a .desktop file is also generated, the assets can go anywhere;
residualvm is also already ok.


Two interresting dependencies of G-D-P I didn't found in rpmfusion
are innoextract & lgogdownloader; when installed a setupexe
sold by GOG.com can be automaticaly downloaded & repacked as a .rpm


That is cool, what are the licenses of these 2 utilities ?


Both are in Debian/main,
- innoextract is MIT licensed & also has it's own rpm repository
- lgogdowloader is 'What The F**k' licensed (=~MIT)

innoextract is now pretty much done,
but lgogdownloader can break anyday when GOG.com changes it's API;
so this needs more frequent updates like youtube-dl .


Ok, so license wise both can go to Fedora proper rather then rpmfusion.

innoextract definitely should go to Fedora proper.



lgogdownloader is more interesting. Which also makes me wonder about
game-data-packager itself. I really do not see any reason for them not to
be in Fedora proper, but I must admit it sort of a gray area.


Both of these utilities are just a single C++ binary built with cmake + boost;
so it should have been easy to build those by hand, but Fedora is lacking
two dependecies: rhash & htmlcxx .

So this is now 4 packages that are needed :-(

I found a recipe here:

http://webcache.googleusercontent.com/search?q=cache:i-GMQKVEu58J:xmodulo.com/download-gog-games-command-line-linux.html+=3=fr=clnk=us

I think I can handle a noarch python package, but when it comes to C++
packages that needs extra versioned libraries that gets a bit more difficult to 
handle.

So for now I'll just use/suggest the innoextract package provided by upstream.


I do not think this is a good idea, we really want to do this properly.

I've taken a quick look, packaging rhash should be easy, it comes
with Makefile-s which properly generate versioned .so libs with a
proper soname at all, and honor DESTDIR, so packaging it really is
not a big deal. And this will actually be a good exercise for showing
that you know the basics of rpm packaging, which is requires to
become a Fedora / rpmfusion packager.

As for htmlcxx it does not come with a buildsys at all, and:

https://github.com/dhoerl/htmlcxx

States:

"The code here is designed to be incorporated directly in your Mac or iOS project 
and not as a library."

So this is what in Fedora we call a copylib, and bundling those is ok,
esp. when upstream does not provide any sort of (API) versioning
what so ever. So you can simply put a snapshot of this in the
same src.rpm as innoextract / lgogdownloader, and use that
directly.


I think you may want to mail Tom Callaway <tcall...@redhat.com>
about how acceptable both of them are for Fedora. He is the go to
persons for questions like these, and any answer he gives is the
definitive answer.

Re: port of game-data-packager to Fedora

[Hans de Goede]

Hi,

On 03-11-15 16:17, Tom Callaway wrote:

On 11/03/2015 02:49 PM, Hans de Goede wrote:

lgogdownloader is more interesting. Which also makes me wonder about
game-data-packager itself. I really do not see any reason for them not to
be in Fedora proper, but I must admit it sort of a gray area.

I think you may want to mail Tom Callaway <tcall...@redhat.com>
about how acceptable both of them are for Fedora. He is the go to
persons for questions like these, and any answer he gives is the
definitive answer.


I'm actually going to defer to FESCo on this, since legally, there is no
issue with either.


Ok,

Alexandre, that means that I'm afraid you will get an early introduction
to some of the red tape processes in Fedora.

Can you please file a ticket with FESCo to discuss the suitability of
both lgogdownloader and game-data-packager.

You will need a Fedora account (you will need one anyways to package
some of the game-data-packager deps):

https://admin.fedoraproject.org/accounts/user/new

And then file a ticket here:

https://fedorahosted.org/fesco/

Thanks,

Hans

Re: port of game-data-packager to Fedora

[Hans de Goede]

Hi,

On 02-11-15 14:54, Alexandre Detiste wrote:

(reposting message first sent to ga...@lists.fedoraproject.org)


Hi,

My redhat/fedora skills were a bit rusty (1998-rusty),
so as an exercice I dediced to port to fedora
the game-data-packager Debian native project I'm working on.

So far, so good, it's already mostly done.

https://github.com/a-detiste/game-data-packager/commits/fedora

That will provide Fedora recipes to automaticaly build noarch .rpm
for currently about 200 games; one of my goal is to cover
all versions of all scummvm games.

It can also download shareware data for doom, quake, descent... games.

http://pkg-games.alioth.debian.org/game-data/


Cool! Do you plan to maintain this for Fedora/rpmfusion in the long
run or is this just a way to exercise your Fedora skills and if we want
to make use of this do we need to find someone to step up from the
rpmfusion community to maintain this ?


Of course it would be better to have real Fedora users that test this;
not only someone that run a minimal install on a container.
(chocolate-doom works over "ssh -X" !)

For example I already spotted that fedora "dynamite" package is lacking
id-shr-extract program needed to unpack wolf3d shareware;
but rpmfusion provides "wolf3d-shareware.noarch" sot this is not a problem.


Heh, I did not know that that little utility I wrote for the wolf3d-shareware /
clonekeen packages ended up in the dynamite svn / debian
dynamite package. If you look at id-shr-extract.c it is a copy
of the extract.c from the rpmfusion sources, and it is:

     Copyright (C) 2007 Hans de Goede  <j.w.r.dego...@hhs.nl>

:)

I do notice that they've stripped the rest of the copyright header though,
which said:

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

...

In the svn patch in the Debian pkg the header is just:

/* utility to extract the .SHR installer data files of early ID software
   shareware games

Copyright (C) 2007 Hans de Goede  <j.w.r.dego...@hhs.nl>
*/

:|

I guess upstream dynamite may have done this because the rest of
dynamite is MIT licensed, I wish they would have just asked though
(maybe they could not find me as me @hhs.nl email has been dead for ages)

For the record I'm fine with re-licensing this tiny blurb of source-code
under MIT.


Two interresting dependencies of G-D-P I didn't found in rpmfusion
are innoextract & lgogdownloader; when installed a setupexe
sold by GOG.com can be automaticaly downloaded & repacked as a .rpm


That is cool, what are the licenses of these 2 utilities ?

Regards,

Hans

Re: port of game-data-packager to Fedora

[Hans de Goede]

Hi,

On 11/03/2015 11:57 AM, Alexandre Detiste wrote:

The fedora support branch has now been completely merged in master :-)

Running it from the git tree is explained here:

http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/doc/adding_a_game.mdwn

$ git clone https://anonscm.debian.org/git/pkg-games/game-data-packager.git
$ make

"Then the `./run` command can be used instead of the
system-installed `game-data-packager` command."


Le mardi 3 novembre 2015, 09:54:35 Hans de Goede a écrit :


Cool! Do you plan to maintain this for Fedora/rpmfusion in the long
run or is this just a way to exercise your Fedora skills and if we want
to make use of this do we need to find someone to step up from the
rpmfusion community to maintain this ?


I'm now running it thourgh virtualbox, maintenance will be more bearable
when I manage to run it in a thin container with full X/OpenGl support.
(systemd-nspawn ?)


Ok, so you do plan to maintain it, that would be great as we
are currently having a shortage of active packagers for rpmfusion.


The LXC recipe I have at hand doesn't work anymore:
https://github.com/lxc/lxc/issues/626


I'm afraid I cannot help there.


---

I managed to build the "dumb" noarch rpm's produced by G-D-P by using
a simple "%files" stanza and shoving the generated specfiles to "rpmbuild -bb";
but I have more difficulties in writing G-D-P's own .spec file,

It should be really easy to package by someone who is used to;
one just needs to do 'make ; make check'
and fill version.py with constants:

http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/debian/rules

---

The generated .rpm always go to ~/rpmbuild/RPMS/noarch/
where the default is $(pwd) on Debian; I didn't found a simple
way to overide this, but maybe that's not desired and
it's better to remove the "--destination" option.


You can pass:

--define "_rpmdir $(pwd)"

to rpmbuild to use the cwd as output dir, the rpms will then be written
to $(pwd/noarch I do not believe there is a way to get rid of the "noarch"
part of the path.


Having a option not to compressing 2GB rpm's that'll be used locally
or rpm's that are zipfile + little else (like Quake .pk? archives) would
be nice too.


Erm, I'm pretty sure you can do that too, but I do not know how.


---

All scummvm & z_code games (Zork, H2G2) should already work as-is.

For the other games, the assets are located where the Debian-packaged
engines except those, thus mostly in /usr/share/games/

See "grep usr/share/games data/*.yaml".

So each engine needs to be reviewed.


Yeah, we typically put game-data under /usr/share/foo rather then
/usr/share/games/foo. But for things like scummvm you likely also
provide a .desktop for the game, passing in the right options to
start the game ?  Then using /usr/share/games should be fine.



---

Bonus: the git tree also include a launcher for the
"Master Levels for Doom II"; you may want to generate
a seperate .rpm with this:

https://wiki.debian.org/Games/MasterLevelsForDoomII

Thnigs like "['update-alternatives', '--list', 'doom']"
needs porting; I'll handle that.






Two interresting dependencies of G-D-P I didn't found in rpmfusion
are innoextract & lgogdownloader; when installed a setupexe
sold by GOG.com can be automaticaly downloaded & repacked as a .rpm


That is cool, what are the licenses of these 2 utilities ?


Both are in Debian/main,
- innoextract is MIT licensed & also has it's own rpm repository
- lgogdowloader is 'What The F**k' licensed (=~MIT)

innoextract is now pretty much done,
but lgogdownloader can break anyday when GOG.com changes it's API;
so this needs more frequent updates like youtube-dl .


Ok, so license wise both can go to Fedora proper rather then rpmfusion.

innoextract definitely should go to Fedora proper.

lgogdownloader is more interesting. Which also makes me wonder about
game-data-packager itself. I really do not see any reason for them not to
be in Fedora proper, but I must admit it sort of a gray area.

I think you may want to mail Tom Callaway <tcall...@redhat.com>
about how acceptable both of them are for Fedora. He is the go to
persons for questions like these, and any answer he gives is the
definitive answer.

Regards,

Hans

Re: rpmfusion Fedora-23 plans ?

[Hans de Goede]

Hi,

On 23-10-15 13:57, Sérgio Basto wrote:

Hello mates

On Qui, 2015-10-22 at 22:27 +0200, Nicolas Chauvet wrote:

2015-10-12 8:30 GMT+02:00 Hans de Goede <j.w.r.dego...@gmail.com>:
 Hi All,

 I'm getting requests to update the gstreamer packages to 1.6.x
 for Fedora-23:

 https://bugzilla.rpmfusion.org/show_bug.cgi?id=3794
 https://bugzilla.rpmfusion.org/show_bug.cgi?id=3795
 https://bugzilla.rpmfusion.org/show_bug.cgi?id=3796

 But AFAIK we are not building any packages for F-23 yet. What
 are the
 plans here ?
Sorry for the lake for answear,


The development/23 repository layout will probably stay some time
after fedora 23 GA, which means the repository won't be frozen.

development/23 is basically f22 packaged resigned with the f23 key,
updates-testing will be f23 specifics packages
(x264/ffmpeg/gst/others)


Once everything got more into shape, we merge them into releases/23
later, but at least, the plan is still to have usable state from
end-user point of view at GA time.(1 week delay!)


As we can see/deduce, kwizart open a window to update F23 with
x264/ffmpeg/gst/mplayer/others , which means a mass rebuild ! and I'd
like try do it in oneshot ...

Following ImportantDependencyLists [1] I have submit x264-0.148
yesterday for F23 .

I think is important show to others mates what is going on so, I had
publish a copy of what was submit in github [2] (and is only a copy!) ,
I don't know if Julian is available , but I'd like see some coordination
to update ffmpeg to latest (2.8.1) , update mplayer as Dominik suggest
and check if there is more packages to update that imply soname bump .


Having some definite plans what to do with ffmpeg for rpmfusion would
be great. I plan to update the gstreamer10-* packages to 1.6.x for
F-23 and gstreamer1-libav now is using ffmpeg rather then libav despite
its name, so I hope that I can build it against the system ffmpeg.

Regards,

Hans

rpmfusion Fedora-23 plans ?

[Hans de Goede]

Hi All,

I'm getting requests to update the gstreamer packages to 1.6.x for Fedora-23:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=3794
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3795
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3796

But AFAIK we are not building any packages for F-23 yet. What are the
plans here ?

Regards,

Hans

Re: Review Swap

[Hans de Goede]

Hi,

On 08/23/2015 08:39 PM, Richard Shaw wrote:

Gotten any takers?


Yes, it has been reviewed by Leigh Scott already,
thanks Leigh.

Let me create the cvs admin request right away.

Regards,

Hans

Review Swap

[Hans de Goede]

Hi All,

I would like to swap a review of:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3740
(easy review).

For a review of one of your Fedora or rpmfusion
packages.

Regards,

Hans

Re: Distribute systemd preset file for services enabled by default?

[Hans de Goede]

Hi,

On 15-07-15 01:59, Richard Shaw wrote:

One of the issues with akmods as of late is that systemd seems to be
ignoring commands in the %post scripts to enable a service and only paying
attention to the preset file distributed by Fedora.

I don't intend to file a FESCO ticket to get akmods added since it doesn't
reside in Fedora.

I believe the simple solution to this problem is to distribute a systemd
preset file which includes akmods as enabled by default.


That sounds like a good solution to me.

Regards,

Hans

x265 in F-22 at 1.2 instead of 1.6 ?

[Hans de Goede]

Hi All,

While updating my system to the new F-22 rpmfusion repos (good job kwizart!),
I had some problems because at one time my system picked up x266-libs-1.6 from
one of the rpmfusion branches I had my .repo files pointing at.

Where as the current F-22 repo (and koji) has 1.2 . 1.2 works fine, but it
seems to me that we should update to 1.6 at some time.

Regards,

Hans

Re: F21 remaining tasks and tracker for issue before RPM Fusion GA

[Hans de Goede]

Hi,

On 10/19/2014 01:15 PM, Nicolas Chauvet wrote:
 https://bugzilla.rpmfusion.org/show_bug.cgi?id=3387

Erm: You are not authorized to access bug #3387. 

Anyways nothing pending from my side AFAIK.

Regards,

Hans

Re: [F21] VLC: dlopen: cannot load any more object with static TLS [Was: VLC does not support the audio or video format h264]

[Hans de Goede]

Hi,

On 08/26/2014 04:56 AM, Ankur Sinha wrote:
 On Tue, 2014-08-26 at 11:55 +1000, Ankur Sinha wrote:
 Something is off here. I can't play webM either. Even totem plays the
 file just fine:
 
 This is what I get when I run it with -vvv:
 
 
 0x7fd4c0008ac8] main input debug: Buffering 0%
 [0x7fd4d4003b38] mkv demux debug: Starting the UI Hook
 [0x7fd4d4003b38] main demux debug: using demux module mkv
 [0x7fd4c0008ac8] main input debug: looking for a subtitle file in 
 /home/asinha/Downloads/Gunda (1998)/
 [0x7fd4d4c045b8] main decoder debug: looking for decoder module matching 
 any: 40 candidates
 [0x7fd4d4c045b8] main decoder warning: cannot load module 
 `/usr/lib64/vlc/plugins/codec/libavcodec_plugin.so' (dlopen: cannot load any 
 more object with static TLS)
 [0x7fd4d4c045b8] main decoder error: corrupt module: 
 /usr/lib64/vlc/plugins/codec/libavcodec_plugin.so
 [0x7fd4d4c045b8] main decoder debug: no decoder modules matched
 [0x7fd4d4c045b8] main decoder error: no suitable decoder module for fourcc 
 `VP80'. VLC probably does not support this sound or video format.
 [0x7fd4d4c045b8] main decoder debug: killing decoder fourcc `VP80', 0 PES in 
 FIFO
 [0x7fd4d4c045b8] main decoder debug: looking for decoder module matching 
 any: 40 candidates
 [0x7fd4d4c045b8] main decoder debug: using decoder module vorbis
 [0x7fd4d4c045b8] vorbis decoder debug: channels:2 samplerate:44100 
 bitrate:128000
 [0x7fd4d4c62358] main demux meta debug: looking for meta reader module 
 matching any: 2 candidates
 
 Irrespective of the file I try to play, it's always the same error:
 
 
 [0x7fa9c8c018f8] main demux debug: using demux module mp4
 [0x7fa9d9b8] main input debug: looking for a subtitle file in 
 /home/asinha/Downloads/
 [0x7fa9cad10c38] main decoder debug: looking for decoder module matching 
 any: 40 candidates
 [0x7fa9cad10c38] main decoder warning: cannot load module 
 `/usr/lib64/vlc/plugins/codec/libavcodec_plugin.so' (dlopen: cannot load any 
 more object with static TLS)
 [0x7fa9cad10c38] main decoder error: corrupt module: 
 /usr/lib64/vlc/plugins/codec/libavcodec_plugin.so
 [0x7fa9cad10c38] main decoder debug: no decoder modules matched
 [0x7fa9cad10c38] main decoder error: no suitable decoder module for fourcc 
 `h264'. VLC probably does not support this sound or video format.
 [0x7fa9cad10c38] main decoder debug: killing decoder fourcc `h264', 0 PES in 
 FIFO
 [0x7fa9cad10c38] main decoder debug: looking for decoder module matching 
 any: 40 candidates
 [0x7fa9cad10c38] main decoder debug: using decoder module faad
 [0x7fa9cad2c668] main demux meta debug: looking for meta reader module 
 matching any: 2 candidates
 [0x7fa9cad2c668] lua demux meta debug: Trying Lua scripts in 
 /home/asinha/.local/share/vlc/lua/meta/reader
 
 I've tried to see what the error means. No luck yet. Anyone have a clue?

Yes, this seems to be the same problem as with running calibre on f21 / rawhide:

https://bugzilla.redhat.com/show_bug.cgi?id=1124987

Esp see:

https://bugzilla.redhat.com/show_bug.cgi?id=1124987#c15

You could try this glibc scratch build, which increases the static TLS limit:

http://koji.fedoraproject.org/koji/taskinfo?taskID=7429597

Grab it while it is still around, it will likely be recycled soon. If this helps
you should probably file a bug against glibc in Fedora, linking to the calibre
bug report.

Regards,

Hans

Re: ffmpeg-2.3.1 released

[Hans de Goede]

Hi,

On 08/07/2014 01:44 PM, Sérgio Basto wrote:
 On Ter, 2014-08-05 at 07:52 +0200, Julian Sikorski wrote:
 - audacious-plugins-freeworld: fails due to missing glib.h - looks
 like
 it is not related to ffmpeg
 
 bug opened https://bugzilla.rpmfusion.org/show_bug.cgi?id=3327 , I add
 Hans de Goede in CC ... 

I've just started a build fixing this.

Regards,

Hans

Re: Volunteering to help out as a sysadmin

[Hans de Goede]

Hi,

On 08/04/2014 07:11 AM, Jonathan Dieter wrote:
 So, as a result of the earlier problems we had with wiki defacement, I'm 
 volunteering to help out as an RPM Fusion sysadmin.  I'm happy to do whatever 
 work needs to be done, whether it's simple, like setting up SSL for the 
 config page in the wiki, or more difficult, like helping switch us over to 
 git+koji.
 
 In my $dayjob, I work as a sysadmin for a school in Beirut, Lebanon, where we 
 run Fedora on most of our desktops.  I have set up and maintained a koji 
 system for the school for the last four years, and I also wrote the 
 yum-presto plugin that (at least in older Fedora releases, it's built into 
 yum in newer releases) enables the use of deltarpms in Fedora.  I've been 
 involved with Fedora for the last seven years, and have been peripherally 
 involved with RPM Fusion on at least a few occasions, and have provided 
 hosting for a few users going through the RPM Fusion package review process.

Cool.

First of all many thanks for volunteering.

You sound like an excellent candidate for the job.

You certainly get my +1, if it were me I would be handing you
the keys to the castle right away, but I'm not one of the current
sysadmins, and as such I've no keys to give away.

And then there is of course the technical problem of giving
virtual keys away in a secure manner. But assuming the current
sysadmins take you up on your offer I'm sure you can find a
way to do that.

Regards,

Hans

Re: New rpmfusion-developers list member introduction - attempt #2

[Hans de Goede]

Hi Bob,

On 07/23/2014 08:25 PM, Bob Lightfoot wrote:
  Dear RPM Fusion Developers:
   I am a fedora user since F8 and a participant in their QA process
  since about F13. I use mostly centos on my workstations and server,
  but still run several vm to test Fedora.  I recently began playing
  with mock and doing rebuilds of my favorite packages for use on
  Centos6 and Centos7.  I am not very fluent with either git or cvs so
  this will be a learning curve for me if I wind up helping package or
  develop something.
  Look forward to just watching things for a while.

Welcome to the rpmfusion community.

Note that if you're already a sponsored Fedora packager, you can just
submit packages for review and/or review others review requests.

If you're not yet a Fedora packager, we would prefer you package
something for Fedora proper first, and go through the Fedora
sponsoring process. But if you have nothing you want to package for
Fedora (hard to believe) and do want to package something for
rpmfusion we can make an exception.

Regards,

Hans

Infrastructure issue: Cannot upload new sources ?

[Hans de Goede]

Hi All,

I was just trying to upgrade gstreamer1-plugins-ugly to the
latest upstream and I hit this:

[hans@shalem devel]$ make new-sources FILES=gst-plugins-ugly-1.2.3.tar.xz

Checking : gst-plugins-ugly-1.2.3.tar.xz on 
https://cvs.rpmfusion.org/repo/pkgs/upload.cgi...
Uploading: gst-plugins-ugly-1.2.3.tar.xz to 
https://cvs.rpmfusion.org/repo/pkgs/upload.cgi...
curl: (22) The requested URL returned error: 500 Internal Server Error
make: *** [new-sources] Error 1
[hans@shalem devel]$

I've already tried updating my client side certificate, that does not
help.

Regards,

Hans


p.s.

Nicolas, thanks for kicking of -ugly rebuilds for the libcdio dep issue.

It turns out I did have some time to look into this after all, so I decided
to try and rebase the gstreamer1* pkgs to the latest upstream, but I got
stuck because of the above. I'll try again next weekend.

Re: Packaging 3-rd party repositories in rpmfusion

[Hans de Goede]

Hi,

On 02/03/2014 02:14 AM, Ralf Corsepius wrote:

[2nd attempt to answer to this. My initial response from quite a while age 
seems to have gone lost.]

On 01/29/2014 12:12 PM, Alec Leamas wrote:

Formally, this is about review request 3152 for dropbox-repo [1]. From
a more practical POV, it's about users being able to install software
like dropbox more or less out of the box, an area where I think we
really need to improve (as can be seen in all those Fedora XX post
installation guide out there).

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

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

To handle this, my simple proposal is that we handles packaged yum
repositories like this:
- It's ok to package yum repositories listed in [4].
- If anyone wants to change the list in [4] this should be announced
here on rpmfusion-devel, and not done until we agree on it (similar to
how we handle bundling exceptions).

Thoughts. out there?


All in all, I am not OK with rpmfusion shipping other party's repos, because 
such repos are out of Fedora's/Rpmfusion's control/influence.

They open up an arbitrary amount of opportunities for these 3rd parties to 
break, corrupt and damage Fedora installations (Package conflicts, low quality 
packages, malware, spyware, intruded/dead/broken 3rd party servers, etc), 
without Fedora/RPMfusion being able to do anything against it.

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


+1

Regards,

Hans

Re: Packaging 3-rd party repositories in rpmfusion

[Hans de Goede]

Hi,

On 02/03/2014 10:03 PM, Thorsten Leemhuis wrote:
 Hi!
 
 On 03.02.2014 10:52, Hans de Goede wrote:
 On 02/03/2014 02:14 AM, Ralf Corsepius wrote: [...]
 In other words, I'd recommend not doing so, because you guys are 
 likely to be facing very tough times in cases something goes
 wrong with these endorsed 3rd party repos.
 +1
 
 RPM Fusion is something most Fedora users will enable, so IMHO it's
 the ideal place to give users something at hand to reach software that
 can't be in Fedora or RPM Fusion for various reasons – flash player
 for example.
 
 Packages with repo files otoh might not be best way. I guess the best
 way forward would be a small app that points out the risks and
 explains that RPM Fusion is not responsible for content from other
 repos; if the users ACks that let the app put repo file in place.
 
 Just my 2 cent because I always wanted something like the above. Ohh,
 and because my name came up recently in this discussion, as one of
 those that was (is?) considered to be on the (inactive) RPM Fusion
 steering committee. Might be wise to set up a new one. I'm fine if
 those that are most active simply organize something and put it in
 place, you have my blessing. If that's not enough: if you want a
 official vote or something else from me just let me know when and
 where to give what's needed ;-)

+1 to all of the above, I too am fine with some app to enable
additional repos or some such, I just don't like any form of
yum install automatically enabling new out of our control
repos.

Regards,

Hans

repoview not being updated

[Hans de Goede]

Hi all,

Can one of the admins please fix repoview updating, currently it is
not being updated, ie:
http://download1.rpmfusion.org/free/fedora/development/rawhide/x86_64/os/repoview/gstreamer1-libav.html

Points to the quite old 1.1.3, rather then the less old 1.2.0, or the recent 
1.2.1

Regards,

Hans

Re: BuildSys restored re-submit/verify your build

[Hans de Goede]

Hi,

On 10/02/2013 10:54 AM, Nicolas Chauvet wrote:

Hi


Since the buildsys is now functional again


Awesome, many thanks for all your work on rpmfusion, and for getting
the buildsys back up again!

Regards,

Hans

Re: BuildSys restored re-submit/verify your build

[Hans de Goede]

Hi,

On 10/02/2013 11:00 AM, Peter Lemenkov wrote:

2013/10/2 Hans de Goede j.w.r.dego...@gmail.com:

Hi,


On 10/02/2013 10:54 AM, Nicolas Chauvet wrote:


Hi


Since the buildsys is now functional again



Awesome, many thanks for all your work on rpmfusion, and for getting
the buildsys back up again!


~1 month downtime is in no way can be called as awesome.


Yes we seem to have a problem where we don't have enough people
doing infra work, agreed. Still I for one am very grateful for
the people we do have doing this work, and I believe we should
be grateful to them that they are doing this work, which no one
else seems to want to do.

So once more: Thank you Nicolas for all your work on rpmfusion.

Regards,

Hans

Re: Request of bundling exception

[Hans de Goede]

Hi,

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

On 09/28/2013 12:48 PM, Alexandre Moine wrote:

Le 27/09/2013 22:16, Alec Leamas a écrit :

On 09/27/2013 10:02 PM, Richard Shaw wrote:

On Fri, Sep 27, 2013 at 1:23 PM, Alexandre Moine nobra...@fedoraproject.org 
mailto:nobra...@fedoraproject.org wrote:

Hi all,

I'm a new packager in the RpmFusion Project, and in the Fedora Project
in general.
I submitted a review request of the openmw package [1] [2]. And I've a
problem. Openmw include 2 bundled package. So, I apply to make two
exceptions. This is the reason:

For shiny:
Per upstream it is designed to be copied in and is not a stand alone
library.
https://github.com/scrawl/shiny/blob/master/CMakeLists.txt

For oics:
Modified from upstream source.

You can also read our discussion in the openmw forum [3].

Links:
[1]: https://bugzilla.rpmfusion.org/show_bug.cgi?id=2921
[2]: https://openmw.org/en/
[3]: http://forum.openmw.org/viewtopic.php?f=3t=1671start=30

Please, if you have any question, ask me :)


Of course you get my vote, but I'm biased. :)

Richard


To be a little formal, you are required to provide answers to the standard 
questions in [1] before there is a decision. If you try to answer those, things 
will be much easier to sort out.


Oh sorry, I forgot that:
Has the library behaviour been modified? No for shiny, it is developped by a 
member of the openmw project. Yes for Oics. It is modified to work with sdl.
Why haven't the changes been pushed to the upstream library? I don't know... 
But the team has been heavy modified the code.
Could we make the forked version the canonical version within Fedora? No, oics 
is designed to work with openmw. For shiny, it can't to work alone
Are the changes useful to consumers other than the bundling application? No, 
for the same. Oics is designed for openmw. For shiny, I don't know, but I think 
not. It's really designed for openmw.
What is the attitude of upstream towards bundling? The writer of shiny is very 
sympatic (@scrawl). For the writer of OICS, i don't know.
Overview of the security ramifications of bundling.The sources is sure (it's 
remake by developpers of openmw, not dangerous)
Does the maintainer of the Fedora package of the library being bundled have any 
comments about this?  The package does not exist.
Is there a plan for unbundling the library at a later time? For now, no. It's 
difficult to do this, and the openmw have other fish to fry! But, with the 
time, maybe.
Please include any relevant documentation:

shiny project: https://github.com/scrawl/shiny
OICS: http://sourceforge.net/projects/oics/

The discussion about this on the openmw wiki: 
http://forum.openmw.org/viewtopic.php?f=3t=1671start=30

Thank you very much Richard ;)

Alexandre



--alec

PS Yes, its a pain... been there, done that. ;) DS

[1] 
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions




--
Alexandre, Fedora User and Ambassador

Hm, lets try to split this discussion into two: one for shiny and one for OICS.

For shiny: is there a problem to package this separately? The code is 
unmodified, so you could just unbundle a new shiny package, and make sure it 
works with openmw? There is something I don't really get here.

It might be that the shiny package just is some source code and not actually 
linked against.  But that does preclude making a separate package IMHO.   
However, we need more input on this -  I',m on thin ice here.


Shiny clearly falls under the copylib bundling exception, so I see no problem 
with
bundling it.

As for oics given the heavy modifications done to it I'm fine with granting a
bundling exception there too.

Regards,

Hans

Re: Late branching for F-20 because of FFmpeg deps needfix

[Hans de Goede]

Hi,

On 08/26/2013 12:41 PM, Nicolas Chauvet wrote:

Hi,

Given that FFmpeg was updated without all dependencies fixed to work with it, I 
will try to make our devel repository to point to branched/F-20 instead of 
rawhide.
(which should point to F-21 packages already)

Please remind that I'm not going to update the mock config accordingly, so this 
will lead to a difference betweek your mock build and the buildsys.

I will also issue a mass rebuild once most of the packages got fixed and branch 
before the middle of September.

Please fix your package and others failing packages by requesting ACL if needed.


I've fixed libquicktime, gstreamer1-libav and frogatto (for new boost, not 
ffmpeg, building now).

But it seems something has gone wrong with gstreamer1-libav, the build 
completed successfully, but:
http://buildsys.rpmfusion.org/plague-results/fedora-development-rpmfusion_free/gstreamer1-libav/1.1.3-2.fc20/
only has debuginfo rpms, and the logs at:
http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/18240-gstreamer1-libav-1.1.3-2.fc20/
are also incomplete, maybe the disk is full ?

If you want me to help with other packages, a list of packages needing work 
would be useful.

Regards,

Hans

Re: OpenSSL with Elliptic Curve

[Hans de Goede]

Hi,

On 05/12/2013 08:46 AM, Jeff Mendoza wrote:

Hi,

I have worked a bit on:

   Request: OpenSSL with Elliptic Curve, IDEA, MDC-2, RC5 crypto algorithms
   Summary: The OpenSSL toolkit provides support for secure communications 
between machines.
   URL: http://www.openssl.org/
   Why not in Fedora: Because of the problem with software patents: 
https://bugzilla.redhat.com/show_bug.cgi?id=319901
   Notes: OpenSSL is included in Fedora but with Elliptic Curve, IDEA, MDC-2, 
RC5 crypto algorithms disabled.

from the http://rpmfusion.org/Wishlist.

I have a building and working rpm, but I don't know what the name/version 
should be. Is there a standard for packages that replace one in Fedora? I 
thought of calling it openssl-ec, and having it conflict with openssl, but you 
can't use yum to replace it without removing openssl and all it's dependent 
packages. Using 'rpm -e --nodeps' and then installing the replacement works 
fine.


Hmm, I didn't know we had this on our wish list, I must say that given the 
security implications,
I'm not really enthusiastic about having a replacement for openssl in rpmfusion.

We do sometimes use conflicts for -freeworld versions of applications which are 
built with extra
features.

But for libraries we should never use Conflicts, as they may change soname and 
then things will break
hard. The usual approach is instead to install the rpmfusion version of the lib 
into a subdir
of %{_libdir} and then drop in a .conf file into /etc/ld.so.conf.d/ adding that 
dir to the search path
(such a dir will then be searched before %{_libdir}.

Given the special nature of openssl and its tendency to change soname every 
other release, the only
acceptable solution to me would be to:
1) Not Conflict
2) Put the openssl so file in a subdir of %{_libdir}
3) Provide an example file for /etc/ld.so.conf.d/ as %doc
4) Add a README.rpmfusion explaining that the example file needs to be copied 
by the admin to
/etc/ld.so.conf.d/  and containing a big fat warning that rpmfusion cannot 
guarantee timely
security updates to its openssl package, and that the admin may need to disable 
it, falling back
to the rpmfusion version, when a security update to openssl is needed.

Note that this means that a simple yum install openssl-freeworld will do 
nothing but eat some
disk-space. This is by design, so that people doing yum install openssl* or
yum install *-freeworld don't accidentally start depending on our openssl. 
The move to rpmfusion
ssl REALLY needs to be a conscious decision, not a side effect of a badly 
constructed yum command.

Regards,

Hans

Re: FTBFS for F-19 free section

[Hans de Goede]

Hoi,

On 05/08/2013 12:31 AM, Sérgio Basto wrote:

resuming some fails:
lightspark
fails due a cannot find LLVMLinker ,
is not just add BuildRequires: llvm-devel ?


No, it needs some fixes to build with the (new) llvm-3.3, I've
fixed this now, and upgraded it from 0.7.1 to 0.7.2 while
at it. It is currently building for F-19 and devel.

Regards,

Hans

Re: Opencv-nonfree in rpmfusion?

[Hans de Goede]

Hi,

On 05/08/2013 09:54 AM, Ankur Sinha wrote:

Hi folks,

I recently realized that the opencv module in Fedora doesn't contain the
nonfree parts, which are the SURF and SIFT feature detectors. I was
wondering if it's OK to make them available via RPMFusion? Both SIFT and
SURF are widely used feature detectors in vision research. Not having
them around makes all these research folks move away from Fedora.

I'd be happy to maintain the package, if required. I'd just like to have
these available for use.


If you're already a sponsored Fedora packager, then simply follow the steps
documented here to submit an opencv-nonfree package to rpmfusion:
http://rpmfusion.org/Contributors#Submitting_a_new_package

Once you've done that you may want to send a mail to this list asking
for a review swap, otherwise it may take quite long to get a review
done.

Note that we would prefer for opencv-nonfree to just contain a couple
of plugins, or some such, and depend on the Fedora package. If that is
not possible it is allowed to simply copy the Fedora package as base,
add the nonfree bits and make it Conflict with the original, see for
example audacity-nonfree

Regards,

Hans

Re: FTBFS for F-19 free and nonfree section and broken deps

[Hans de Goede]

Hi,

On 05/08/2013 12:51 AM, Sérgio Basto wrote:

On Ter, 2013-05-07 at 23:31 +0100, Sérgio Basto wrote:

On Sáb, 2013-05-04 at 22:04 +0200, Hans de Goede wrote:

Hi,

On 04/24/2013 09:56 PM, Nicolas Chauvet wrote:

Hi,

Just a quick note, that from my list, theses package still aren't rebuilt for 
F-19 on the free section.
   16340   lxdream lxdream-0_9_1-7_fc19
   16324   k9copy  k9copy-2_3_8-3_fc19 ffmpeg/API
   16300   audacity-freeworld  audacity-freeworld-2_0_1-2_fc19

audacity would need an update for fedora counterpart also.


So audacity is taken care of (barring builds which need a
new portaudio to trickle down into the buildroots from Fedora first).

k9copy has also been taken care of, courtesy of Sérgio.

That leaves lxdream, as a first step I've taken a look to see
if there is a new version from upstream, and the latest upstream
release is from Jun 29 2009. Combine that with a %description of:

 ... it is still in heavy development (and many features are
buggy or unimplemented), it is already capable of running many
demos and some games.

And I suggest that we just dead.package it.

mixxx seems to be missing from the list of not build
packages from the free section. Let me know if you need a hand in
fixing it.

Also I wonder if someone has a complete up2date *summary* of any
FTBFS / broken deps issues in non-free (excluding dead.package
packages please).


Hi, we have two kind of lists 1 - FTBFS and 2 - broken deps
for broken deps
I use on my vm with F19.x86_64

repoquery --disablerepo=fedora,updates,updates-testing -a
--pkgnarrow=available --envr | perl -pe 's/^\d+://' | grep -vP kmod|
nvidia|VirtualBox|ufoai|i686|ndiswrapper  list2.txt

and

yum install `cat list2.txt` --skip-broken

Can't install:
bino-1.4.1-2.fc19.x86_64
dvbcut-0.6.1-8.svn179.fc19.x86_64
freecad-0.13-2.fc19.x86_64
freecad-doc-0.13-2.fc19.noarch

lightspark-0.7.1-2.fc19.x86_64
lightspark-mozilla-plugin-0.7.1-2.fc19.x86_64
mlt-ruby-0.8.8-3.fc19.x86_64
rpmfusion-nonfree-package-config-smart-16-3.x86_64

xmms2-nonfree-0.8-4.fc19.x86_64
xmms2-sid-0.8-4.fc19.x86_64
z-push-zarafa-2.0.7-2.fc19.noarch


resuming some fails:
lightspark
fails due a cannot find LLVMLinker ,
is not just add BuildRequires: llvm-devel ?

xmms2-nonfree-0.8-4.fc19.x86_64
xmms2-sid-0.8-4.fc19.x86_64
seems needs a rebuild for new libsid

freecad-0.13-2.fc19.x86_64
Requires: python-collada
No package python-collada available



For FTBFS :
repoquery --disablerepo=fedora,updates,updates-testing -a --envr | perl
-pe 's/^\d+://' | grep -v fc19

Mosaic-2.7-0.3.b5.fc11.x86_64
ProjectX-0.91.0-3.noarch
audacity-freeworld-2.0.0-1.fc18.x86_64
(...)
lxdream-0.9.1-6.fc18.x86_64
mixxx-1.10.0-1.fc18.x86_64
(...)
rpmfusion-nonfree-package-config-smart-16-3.x86_64
(...)
ufoai-2.4-1.fc18.x86_64
ufoai-common-2.4-1.fc18.x86_64
ufoai-data-2.4-1.noarch
ufoai-data-server-2.4-1.noarch
ufoai-doc-2.4-1.fc18.x86_64
ufoai-server-2.4-1.fc18.x86_64
ufoai-tools-2.4-1.fc18.x86_64
ufoai-uforadiant-2.4-1.fc18.x86_64
wormsofprey-data-20051221-4.fc17.noarch


raine-0.50.11-4.fc10 was out of this list because as removed from repos
6 days ago, by Nicolas (kwizart)
but raine is alive with new home http://rainemu.swishparty.co.uk/
I'm trying rebuild it for 0.60.1 but I hadn't much time ...


I've taken a very quick look, and stopped looking when it was still
all i386 assembler, so no x86_64 support let alone arm or any other
archs. This really is not the way to write software in 2013.

Note I'm not saying that you should not re-vive it, but I took a
quick look and then decided I've better ways to spend my time.

Regards,

Hans

Re: FTBFS for F-19 free section

[Hans de Goede]

Hi,

On 05/01/2013 02:28 PM, Sérgio Basto wrote:

On Qua, 2013-05-01 at 09:14 +0200, Hans de Goede wrote:

Hi,

On 04/29/2013 03:36 PM, Nicolas Chauvet wrote:

2013/4/29 Hans de Goede j.w.r.dego...@gmail.com 
mailto:j.w.r.dego...@gmail.com

 Hi,


 On 04/27/2013 04:07 AM, Sérgio Basto wrote:

 ...
 sidplay-2.0.9-13.fc17.x86_64


 While working on sidplay, I found out there is a new upstream for it 
called sidplayfp,
 which fixes the issues making sidplay nonfree. So I've packaged 
libsidplayfp and
 sidplay for Fedora. Also the sid plugin for audacious has been changed to 
build with
 libsidplayfp and this has now landed in Fedora-updates for F-19+, so the 
following
 packages can now be retired from rpmfusion:

 sidplay
 sidplay-libs
 audacious-plugins-nonfree

 I'll go and create dead.package files for them in their F-19+ branches. 
What is
 the proper procedure for blocking these from inclusion in rpmfusion F-19+ 
repos ?


I will manually remove them from the repository.
taking care of that before the next push.

BTW, what about an audacity update (in both fedora and RPM Fusion ?)
It looks unmaintained.


I've pinged the Fedora maintainer and he admits he was away for a while, but he 
is back now.

I've offered him help on getting the Fedora packages upgraded to 2.0.3, once 
that is done
I'll also take care of the rpmfusion packages.


We already have a ticket to fix audacity :
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2707


Ok, I've committed all the necessary changes for a new 2.0.3 based audacity 
package to the
devel branch in CVS. Building this needs to wait for tomorrows rawhide push as 
it needs a new
enough portaudio.

This problem extends to F-19, do we have updates-testing in the F-19 buildroot? 
If not we
will need to wait 3 days, so that I can push the new portaudio to the stable 
F-19 updates
repo, and hope we don't run into some freeze.

Regards,

Hans

Re: FTBFS for F-19 free section

[Hans de Goede]

Hi,

On 04/24/2013 09:56 PM, Nicolas Chauvet wrote:

Hi,

Just a quick note, that from my list, theses package still aren't rebuilt for 
F-19 on the free section.
  16340   lxdream lxdream-0_9_1-7_fc19
  16324   k9copy  k9copy-2_3_8-3_fc19 ffmpeg/API
  16300   audacity-freeworld  audacity-freeworld-2_0_1-2_fc19

audacity would need an update for fedora counterpart also.


So audacity is taken care of (barring builds which need a
new portaudio to trickle down into the buildroots from Fedora first).

k9copy has also been taken care of, courtesy of Sérgio.

That leaves lxdream, as a first step I've taken a look to see
if there is a new version from upstream, and the latest upstream
release is from Jun 29 2009. Combine that with a %description of:

 ... it is still in heavy development (and many features are
buggy or unimplemented), it is already capable of running many
demos and some games.

And I suggest that we just dead.package it.

mixxx seems to be missing from the list of not build
packages from the free section. Let me know if you need a hand in
fixing it.

Also I wonder if someone has a complete up2date *summary* of any
FTBFS / broken deps issues in non-free (excluding dead.package
packages please).

Regards,

Hans

Re: FTBFS for F-19 free section

[Hans de Goede]

Hi,

On 04/29/2013 03:36 PM, Nicolas Chauvet wrote:

2013/4/29 Hans de Goede j.w.r.dego...@gmail.com 
mailto:j.w.r.dego...@gmail.com

Hi,


On 04/27/2013 04:07 AM, Sérgio Basto wrote:

...
sidplay-2.0.9-13.fc17.x86_64


While working on sidplay, I found out there is a new upstream for it called 
sidplayfp,
which fixes the issues making sidplay nonfree. So I've packaged 
libsidplayfp and
sidplay for Fedora. Also the sid plugin for audacious has been changed to 
build with
libsidplayfp and this has now landed in Fedora-updates for F-19+, so the 
following
packages can now be retired from rpmfusion:

sidplay
sidplay-libs
audacious-plugins-nonfree

I'll go and create dead.package files for them in their F-19+ branches. 
What is
the proper procedure for blocking these from inclusion in rpmfusion F-19+ 
repos ?


I will manually remove them from the repository.
taking care of that before the next push.

BTW, what about an audacity update (in both fedora and RPM Fusion ?)
It looks unmaintained.


I've pinged the Fedora maintainer and he admits he was away for a while, but he 
is back now.

I've offered him help on getting the Fedora packages upgraded to 2.0.3, once 
that is done
I'll also take care of the rpmfusion packages.

Regards,

Hans

Re: FTBFS for F-19 free section

[Hans de Goede]

Hi,

On 04/27/2013 04:07 AM, Sérgio Basto wrote:

On Qua, 2013-04-24 at 21:56 +0200, Nicolas Chauvet wrote:

Hi,


Just a quick note, that from my list, theses package still aren't
rebuilt for F-19 on the free section.

16340   lxdream lxdream-0_9_1-7_fc19
16324   k9copy  k9copy-2_3_8-3_fc19 ffmpeg/API
16300   audacity-freeworld  audacity-freeworld-2_0_1-2_fc19



audacity would need an update for fedora counterpart also.


a simple query with repoquery give us the answer :

repoquery --disablerepo=fedora,updates,updates-testing -a --envr | perl -pe 's/^\d+://' | grep -vP 
fc19 | grep -P fc\d+

Mosaic-2.7-0.3.b5.fc11.x86_64
(...)
(...)
libdvbpsi-0.2.2-2.fc17.i686
libdvbpsi-0.2.2-2.fc17.x86_64
libdvbpsi-devel-0.2.2-2.fc17.i686
libdvbpsi-devel-0.2.2-2.fc17.x86_64
(...)
(...)
mixxx-1.10.0-1.fc18.x86_64
raine-0.50.11-4.fc10.i386
rpmfusion-free-remix-kickstarts-0.18.0-0.1.fc18.noarch
rpmfusion-nonfree-remix-kickstarts-0.18.0-0.1.fc18.noarch
(...)
sidplay-2.0.9-13.fc17.x86_64


While working on sidplay, I found out there is a new upstream for it called 
sidplayfp,
which fixes the issues making sidplay nonfree. So I've packaged libsidplayfp and
sidplay for Fedora. Also the sid plugin for audacious has been changed to build 
with
libsidplayfp and this has now landed in Fedora-updates for F-19+, so the 
following
packages can now be retired from rpmfusion:

sidplay
sidplay-libs
audacious-plugins-nonfree

I'll go and create dead.package files for them in their F-19+ branches. What is
the proper procedure for blocking these from inclusion in rpmfusion F-19+ repos 
?

Regards,

Hans

abrt wants a mirrorlist-debug

[Hans de Goede]

Hi,

While looking at abrt bug-filing logs I noticed:

Could not retrieve mirrorlist http://rpm.livna.org/mirrorlist-debug error was
14: HTTP Error 404 - Not Found

I think we should fix this ...

Regards,

Hans

Re: Mass rebuilt for F-19 on RPM Fusion - next week

[Hans de Goede]

Hi,

On 03/19/2013 11:59 PM, Sérgio Basto wrote:


better late than never , the fails are:
16390   zsnes   zsnes-1_51-13_fc19
16371   terminatorX terminatorX-3_84-3_fc19
16367   SheepShaver SheepShaver-2_3-0_11_20060514_fc19
16357   normalize   normalize-0_7_7-8_fc19


I've fixed normalize and fired of builds for F19+, looks
like the rawhide build failed due the hitting a mirror
sync window. Will requeue the build tomorrow.


16350   motion  motion-3_3_0-trunkREV534_fc19
16347   mixxx   mixxx-1_10_1-2_fc19
16340   lxdream lxdream-0_9_1-7_fc19
16324   k9copy  k9copy-2_3_8-3_fc19
16312   foo2zjs foo2zjs-0_2005-4_fc19
16306   DVDAuthorWizard DVDAuthorWizard-1_4_6-5_fc19
16309   faad2   faad2-2_7-3_fc19
16391   xvidcorexvidcore-1_3_2-4_fc19
16303   cairo-dock  cairo-dock-2_4_0_2-2_fc19
16301   BasiliskII  BasiliskII-1_0-0_20060501_3_fc19
16300   audacity-freeworld  audacity-freeworld-2_0_1-2_fc19
16387   xvidcorexvidcore-1_3_2-4_fc19
16386   xvid4conf   xvid4conf-1_12-6_fc19

but don't found any with gcc 4.8 problems ...


On 2nd mass rebuild , I saw this build fails:

16501   sidplay sidplay-2_0_9-14_fc19
16510   ufoai   ufoai-2_4-2_fc19
16499   raine   raine-0_50_11-8_fc19
16492   OpenEXR_Viewers-nonfree
OpenEXR_Viewers-nonfree-1_0_2-12_fc19


Regards,

Hans

Re: Mass rebuilt for F-19 on RPM Fusion - next week

[Hans de Goede]

Hi,

On 03/24/2013 07:46 PM, Andrea Musuruane wrote:

On Tue, Mar 12, 2013 at 7:43 PM, Andrea Musuruane musur...@gmail.com 
mailto:musur...@gmail.com wrote:

On Tue, Mar 12, 2013 at 6:15 PM, Sérgio Basto ser...@serjux.com 
mailto:ser...@serjux.com wrote:

better late then never , the fails are:
16390   zsnes   zsnes-1_51-13_fc19


I found this patch made by Debian to fix this issue:

http://patch-tracker.debian.org/patch/series/view/zsnes/1.510+bz2-5/0012-Fix-build-with-gcc-4.7.patch

I'll apply it soon.


I tried to fix this issue but I hit another. Now when I build with mock I get 
the following error:

[...]
g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom 
-fasynchronous-unwind-tables -I. -D__UNIXSDL__  -I/usr/include/SDL 
-D_GNU_SOURCE=1 -D_REENTRANT  -D__LIBAO__ -D__OPENGL__ -march=i386 
-D__RELEASE__ -fno-rtti -o tools/depbuild tools/depbuild.cpp tools/fileutil.o 
tools/strutil.o
tools/depbuild.cpp: In function 'int main(int, const char* const*)':
tools/depbuild.cpp:214:30: warning: comparison between signed and unsigned 
integer expressions [-Wsign-compare]
tools/depbuild.cpp: In function 'void dependency_calculate_asm(const char*)':
tools/depbuild.cpp:135:26: warning: ignoring return value of 'int system(const 
char*)', declared with attribute warn_unused_result [-Wunused-result]
/tmp/ccTlkeDY.o: In function `__exchange_and_add':
/usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ext/atomicity.h:48:
 undefined reference to `__atomic_fetch_add_4'
tools/strutil.o: In function `__exchange_and_add':
/usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ext/atomicity.h:48:
 undefined reference to `__atomic_fetch_add_4'
/usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ext/atomicity.h:48:
 undefined reference to `__atomic_fetch_add_4'
collect2: error: ld returned 1 exit status
make: *** [tools/depbuild] Error 1
errore: Stato d'uscita errato da /var/tmp/rpm-tmp.m63Y3l (%build)
Errori di compilazione RPM:
 Stato d'uscita errato da /var/tmp/rpm-tmp.m63Y3l (%build)
Child return code was: 1
EXCEPTION: Command failed. See logs for output.
  # ['bash', '--login', '-c', 'rpmbuild -bb --target i686 --nodeps 
builddir/build/SPECS/zsnes.spec']
Traceback (most recent call last):
   File /usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py, line 
70, in trace
 result = func(*args, **kw)
   File /usr/lib/python2.7/site-packages/mockbuild/util.py, line 359, in do
 raise mockbuild.exception.Error, (Command failed. See logs for output.\n # 
%s % (command,), child.returncode)
Error: Command failed. See logs for output.
  # ['bash', '--login', '-c', 'rpmbuild -bb --target i686 --nodeps 
builddir/build/SPECS/zsnes.spec']
LEAVE do -- EXCEPTION RAISED

I can't understand the cause.

The SRPM is here:
https://dl.dropbox.com/u/12575912/zsnes-1.51-14.fc17.src.rpm

Does someone has a spare cycle?


Just threw a few spare cycles at this, the error you were seeing was caused by
passing force_arch=i386 to configure, changing this to force_arch=i686
fixed that error.

Then I hit a crash on startup due to zsnes feeding a (partly) uninitialized
struct to libao, fixed that too.

I also cleaned up the specfile a bit:
-drop obsolete buildroot stuff
-use up2date gtk-icon-cache scriptlets
-don't pass --vendor to desktop-file-install on F-19+

I've commit all this to CVS for F19+ and started builds, chances are the
rawhide build will fail due to hitting a mirror sync window. If this happens
I'll requeue it tomorrow.

Regards,

Hans

Re: Mass rebuilt for F-19 on RPM Fusion - next week

[Hans de Goede]

Hi,

On 03/24/2013 10:25 PM, Orcan Ogetbil wrote:

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?


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.

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

IE for this build:
PLAGUE_CLIENT_CONFIG=$HOME/.plague-client-rpmfusion.cfg plague-client requeue 
16653

Regards,

Hans

Re: Mass rebuilt for F-19 on RPM Fusion - next week

[Hans de Goede]

Hi,

On 03/19/2013 11:59 PM, Sérgio Basto wrote:

Hi,
On Ter, 2013-03-12 at 17:15 +, Sérgio Basto wrote:

On Ter, 2013-03-05 at 22:00 +0100, Nicolas Chauvet wrote:

2013/3/4 Sérgio Basto ser...@serjux.com
 On Sáb, 2013-02-23 at 15:51 +0100, Nicolas Chauvet wrote:
  Hi,
 
  As the mass rebuild for fedora is already passed, I would
 like to
  schedule a rebuilt of the RPM Fusion package in devel/F-19
 next week.
 
  There is a need to check if the devel branches are higher
 for each
  package.


 Hi,
 Mass rebuild on RPMFusion, has already finished ?
 what is the list of those packages that not compiled ?

Mass rebuilt occurred on the free section based on packages still
using dist tag older than .fc19.
This was a wrong assumption as some packages was not rebuilt with
gcc48 whereas built during the fc19 development process.

I will try to resubmit a list later unless someone come with such a
list.

Build failing were from jobs 16386 to 16390 as seen in:
http://buildsys.rpmfusion.org/build-status/failed.psp


better late than never , the fails are:
16390   zsnes   zsnes-1_51-13_fc19
16371   terminatorX terminatorX-3_84-3_fc19
16367   SheepShaver SheepShaver-2_3-0_11_20060514_fc19
16357   normalize   normalize-0_7_7-8_fc19
16350   motion  motion-3_3_0-trunkREV534_fc19
16347   mixxx   mixxx-1_10_1-2_fc19
16340   lxdream lxdream-0_9_1-7_fc19
16324   k9copy  k9copy-2_3_8-3_fc19
16312   foo2zjs foo2zjs-0_2005-4_fc19
16306   DVDAuthorWizard DVDAuthorWizard-1_4_6-5_fc19
16309   faad2   faad2-2_7-3_fc19
16391   xvidcorexvidcore-1_3_2-4_fc19
16303   cairo-dock  cairo-dock-2_4_0_2-2_fc19
16301   BasiliskII  BasiliskII-1_0-0_20060501_3_fc19
16300   audacity-freeworld  audacity-freeworld-2_0_1-2_fc19
16387   xvidcorexvidcore-1_3_2-4_fc19
16386   xvid4conf   xvid4conf-1_12-6_fc19

but don't found any with gcc 4.8 problems ...


As part of my efforts to make rpmfusion esound dependency free,
as there are plans in Fedora to remove esound, I've fixed
BasiliskII and SheepShaver (which were FTBFS since F11 !), I've
also updated them to a much newer version.

I'll probably also take a look at fixing zsnes one of these days,



On 2nd mass rebuild , I saw this build fails:

16501   sidplay sidplay-2_0_9-14_fc19


Not sure who maintains this, but I'm interested in this, so I'll
take a look one of these days.


16510   ufoai   ufoai-2_4-2_fc19
16499   raine   raine-0_50_11-8_fc19
16492   OpenEXR_Viewers-nonfree
OpenEXR_Viewers-nonfree-1_0_2-12_fc19


Regards,

Hans

Re: list of packages from repo rpmfusion-free that doesn't install on F18

[Hans de Goede]

Hi,

On 10/22/2012 12:44 AM, Sérgio Basto wrote:

Updated list:

autopano-sift-C-2.5.1-6.fc17.x86_64 from rpmfusion-free
bombono-dvd-1.2.0-4.20120616gitcdab110.fc18.2.x86_64 from rpmfusion-free
cmus-2.4.2-4.fc18.x86_64 from rpmfusion-free
kmediafactory-0.8.1-1.fc18.x86_64 from rpmfusion-free
kmediafactory-devel-0.8.1-1.fc18.x86_64 from rpmfusion-free
kmediafactory-libs-0.8.1-1.fc18.x86_64 from rpmfusion-free
mlt-ruby-0.8.0-2.fc18.x86_64 from rpmfusion-free
motion-3.3.0-trunkREV534.fc18.2.x86_64 from rpmfusion-free
pangzero-1.3-4.fc17.noarch from rpmfusion-free


After much work on getting it back in shape, it now has
been build for F-18+


picard-freeworld-1.0-1.fc18.x86_64 from rpmfusion-free



smc-1.9-11.fc18.x86_64 from rpmfusion-free
smc-music-4.1-2.fc17.noarch from rpmfusion-free


Tested the rebuild kwizard did, works fine.


sox-plugins-freeworld-14.3.2-3.fc18.x86_64 from rpmfusion-free
vbam-wx-1.8.0.1054-5.fc18.x86_64 from rpmfusion-free
west-chamber-0.0.1-8.20101017svn.fc18.x86_64 from rpmfusion-free
xmms2-avcodec-0.8-2.fc18.x86_64 from rpmfusion-free
xmms2-freeworld-0.8-2.fc18.x86_64 from rpmfusion-free


Regards,

Hans

Re: list of packages from repo rpmfusion-free that doesn't install on F18

[Hans de Goede]

Hi,

On 11/02/2012 02:26 AM, Sérgio Basto wrote:

On Qui, 2012-11-01 at 20:23 +0100, Nicolas Chauvet wrote:


2012/10/27 Sérgio Basto ser...@serjux.com
 I suggest rebuild this ones for resolve dependencies.




   cmus-2.4.2-4.fc18.x86_64 from rpmfusion-free
 libavformat.so.53
There is a new upstream release, please submit a bug. Either there is
an active maintainer or the package get dropped.


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


   mlt-ruby-0.8.0-2.fc18.x86_64 from rpmfusion-free
 ruby(abi) = 1.8
same (mlt-0.8.2)


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






   pangzero-1.3-4.fc17.noarch from rpmfusion-free
 perl(SDL::Font)
If the package have been dropped, same is to expect with this one.
Unless a new maintainer can sort out a better solution.



I think I don't explain well, pangzero needs rebuild for new perl
version.
I just rebuild here, and no problems.


Erm, no, we've a new perl-SDL and that has a completely different API,
perl is a dynamic language, so a package building does not mean much.

Have you actually tried running it ?

Anyways I'm working on a new version for pangzero fixing this.

Regards,

Hans

Re: list of packages from repo rpmfusion-free that doesn't install on F18

[Hans de Goede]

Hi,

On 11/01/2012 08:23 PM, Nicolas Chauvet wrote:

   pangzero-1.3-4.fc17.noarch from rpmfusion-free
perl(SDL::Font)

If the package have been dropped, same is to expect with this one.
Unless a new maintainer can sort out a better solution.


I've been working on fixing this up, and almost have it ready, see:
https://github.com/jwrdegoede/pangzero/commits/master

It was a bit of work, but I have it working pretty nicely with the
new perl-SDL now. I still need to do a tiny but more polishing and
then I'll commit and build an updated package.


   smc-1.9-11.fc18.x86_64 from rpmfusion-free
libboost_system.so.1.48.0
   smc-music-4.1-2.fc17.noarch from rpmfusion-free
libboost_filesystem.so.1.48.0

rebuilt submitted


I had that on my todo, but all my time went into pangzero, Thanks!

Regards,

Hans

New gstreamer-1.0 plugin packages need reviews for F-18

[Hans de Goede]

Hi,

In F-18+ most apps are moving to gstreamer-1.0, this needs new
packages for the rpmfusion hosted gstreamer plugins, this reason
this needs new packages is that the old 0.10 gstreamer will stay
around for a while, so the new packages will need to be parallel
installable like their Fedora counterparts.

Please help getting these plugins reviewed ASAP, as without them
apps like totem are not capable to play a lot of content in F-18+

Here is a list of all Review Requests for this:
2470 - Review request: vo-aacenc - VisualOn Advanced Audio Coding (AAC) encoder
2471 - Review request: vo-amrwbenc - VisualOn Adaptive Multi Rate Wideband 
speech encoder
2472 - Review request: gstreamer1-libav - GStreamer 1.0 FFmpeg-based plug-ins
2473 - Review request: gstreamer1-plugins-bad-freeworld - GStreamer 1.0 streaming media 
framework bad plug-ins
2474 - Review request: gstreamer1-plugins-ugly - GStreamer 1.0 streaming media framework 
ugly plug-ins

Thanks  Regards,

Hans

Vacation hansg July 13th - July 20th

[Hans de Goede]

Hi All,

I'm going on vacation for a week starting tomorrow, and I will *not*
be reading email, etc. during that time.

Regards,

Hans

Re: rpms/mpg123/EL-6 .cvsignore, 1.5, 1.6 mpg123.spec, 1.5, 1.6 sources, 1.5, 1.6

[Hans de Goede]

Hi,

On 07/02/2012 07:34 PM, Richard Shaw wrote:

On Mon, Jul 2, 2012 at 11:50 AM, Nicolas Chauvet kwiz...@gmail.com wrote:

2012/7/2 Richard Shaw hobbes1...@gmail.com:

Maybe we need to update this guidelines in there area... How do I know
who also maintainers this package? Also, are we not supposed to
general build the latest released version of a package? It looked like
Hans was the main Fedora maintainer and he has mentioned several times
in the past he has no interest in EL...

Who do you believe you will abuse with this twisted reasoning ?
You are a co-maintainer of the devel branch along with EL-6.

Please review the http://fedoraproject.org/wiki/Updates_Policy and
consider EL-6 as a deep stable branch
not a branch ahead of any fedora development branch.


Since I only request access to the EL-6 I was unaware that that also
grants me access to the devel branch. Shall I go ahead and update the
devel branch then?


Yes please, and while at it can
you also fix: https://bugzilla.rpmfusion.org/show_bug.cgi?id=1898
please?

Thanks  Regards,

Hans

Re: FFmepg rebuild Schedule ?

[Hans de Goede]

Hi,

On 06/24/2012 05:41 PM, Sérgio Basto wrote:

On Dom, 2012-06-24 at 16:22 +0200, Hans de Goede wrote:

Hi,

Just a quick note, while doing a local build of all
deps to work on my ffmpeg dependent packages, I
noticed the following in x264's config.log file:

checking for gf_malloc(1); gf_free(NULL); in gpac/isomedia.h... no
Failed commandline was:
--
gcc conftest.c -m64  -Wall -I. -I$(SRCPATH) -O2 -g -pipe -Wall -Wp,-D_FORTIFY_S
conftest.c: In function 'main':
conftest.c:2:24: error: ignoring return value of 'malloc', declared with attrib
cc1: all warnings being treated as errors
--
Failed program was:
--
#include gpac/isomedia.h
int main () { gf_malloc(1); gf_free(NULL); return 0; }
--

I think we should fix this ...


checking for gpac/isomedia.h... yes
checking for gf_isom_set_pixel_aspect_ratio(0,0,0,0,0); in
gpac/isomedia.h... yes
checking for gf_malloc(1); gf_free(NULL); in gpac/isomedia.h... no

not have gf_malloc and gf_free , is problematic ?


No, x264 thinking it does not have them, while they are actually available is
problematic (I don't know if it is causing any real issues, but it is wrong).

Look at the error closely:

 conftest.c: In function 'main':
 conftest.c:2:24: error: ignoring return value of 'malloc', declared with 
attrib
 cc1: all warnings being treated as errors

So the problem is that -Wall -Werror somehow is in the CFLAGS when the tests 
run,
causing the test to fail (where it should succeed)


what you suggest to fix ?


Fix the test code, changing it to something like:

void *p; p = gf_malloc(1); gf_free(p);

Regards,

Hans

Re: FFmepg rebuild Schedule ?

[Hans de Goede]

Hi,

I've done a local rebuild of the ffmpeg stack to prepare and test my packages
for the ffmpeg bump.

audacious-plugins-freeworld is committed and ready to build as soon as the
new ffmpeg is in place

gstreamer-ffmpeg is a problem, as upstream is using/supporting only libav and 
not
ffmpeg, and the 2 seem to have grown apart quite a bit API wise with the last 
ffmpeg
release. I've been looking at patching gstreamer-ffmpeg to build with ffmpeg 
rather
then libav, but the 2 really have grown too far apart, requiring too many 
changes,
which will surely introduce a lot of bugs.

Some examples of the issues are:
-ffmpeg no longer has URLProtocol and av_register_protocol publicly available, 
they
are still used internally so I've hacked around this, but this hack will 
require some
changes to our ffmpeg packages, to make the interfaces public again.
-AVCodec no longer has a palettectrl member, instead the palette now is passed 
as
 data[1] to image read/write functions. Supporting this model requires major 
surgery
 to gstreamer-ffmpeg

So we've 4 options:

1) Try to patch gstreamer-ffmpeg to build with new ffmpeg, tried and failed
2) Build gstreamer-ffmpeg with an old ffmpeg-compat. May work for now, but 
seems like
a dead end in the long run, as I'm sure we don't want to have an ffmpeg-compat
stick around for ever, and having one stick around for ever would seem like a 
bad
idea from a security pov.
3) Build gstreamer-ffmpeg with its bundled libav copy, this is actually the 
advised
way to ship gstreamer-ffmpeg by upstream.
4) Package libav in such a way that it is parallel installable to ffmpeg, use a 
system
libav with gstreamer-ffmpeg

For now I believe that 3. is the best solution, if we get more packages which 
only work
with libav and not with with ffmpeg we can move to 4. Alternatively if upstream 
libav
starts making similar API changes as ffmpeg, and gstreamer-ffmpeg moves to the 
new
API's we could try 1. again.

Regards,

Hans

Re: FFmepg rebuild Schedule ?

[Hans de Goede]

Hi,

Just a quick note, while doing a local build of all
deps to work on my ffmpeg dependent packages, I
noticed the following in x264's config.log file:

checking for gf_malloc(1); gf_free(NULL); in gpac/isomedia.h... no
Failed commandline was:
--
gcc conftest.c -m64  -Wall -I. -I$(SRCPATH) -O2 -g -pipe -Wall -Wp,-D_FORTIFY_S
conftest.c: In function 'main':
conftest.c:2:24: error: ignoring return value of 'malloc', declared with attrib
cc1: all warnings being treated as errors
--
Failed program was:
--
#include gpac/isomedia.h
int main () { gf_malloc(1); gf_free(NULL); return 0; }
--

I think we should fix this ...

Regards,

Hans

Re: Qtractor alternatives revisited

[Hans de Goede]

On 06/11/2012 06:06 AM, Rex Dieter wrote:

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.



Works for me.


And for me too, +1

Regards,

Hans

Re: qtractor moved to Fedora

[Hans de Goede]

Hi,

On 05/18/2012 11:38 AM, Brendan Jones wrote:

On 05/18/2012 03:14 AM, Orcan Ogetbil wrote:

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


The reason why we repackaged this in Fedora is so that we can include it in the 
upcoming Fedora Audio spin.

I'm not keen on the scenario where both packages are present and agree with 
Orcan that the alternatives approach does not really add any benefit. What is 
is so bad with a qtractor-freeworld replacing the Fedora version? Presumably 
anyone who installs this package knows what they are doing and why.


The problem is that to replace the package, it will need a higher EVR, and
then when Fedora bumps version the Fedora version may become newer and
then yum will upgrade to the Fedora version removing the mp3 support.

So the best solution is either using alternatives or a conflict. I'm sure a
conflict + provides (in case anything depends on qtractor) will work fine and
that is a very simple solution. Having 2 packages with the same name in 2
different repo is just asking for trouble...

Regards,

Hans

Re: qtractor moved to Fedora

[Hans de Goede]

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.

Regards,

Hans

Re: Bundled libs found in sox-plugins-freeworld (and therefor sox in Fedora)

[Hans de Goede]

Hi,

On 03/22/2012 03:05 PM, Richard Shaw wrote:

While getting my package reviewed[1] it was discovered that sox is
bundling two libraries, libgsm and lpc10.

libgsm is already available so we're using the configure option to use
the system installed library and patching around configure still
looking for the directory (since it's now removed in %prep)

lpc10 is another problem all together. There doesn't appear to be an
upstream for it although the spandsp-devel package provides the header
it doesn't appear to supply the library (unless it's statically linked
into the main library).

The sox project has modified their bundled version of lpc10 so I guess
I'm asking if we can consider it a fork and leave it alone?


If Fedora is not packaging it in anyway and there is no clear upstream
then I guess considering it a fork or even a private lib is fine.

Regards,

Hans