Re: libdvdcss in RPM Fusion ?
On 06.09.2016 12:28, Xavier Bachelot wrote: > > If mirroring libdvdcss is still a concern, we may want to ship libdvdcss > in a dedicated repo so mirrors can exclude it easily. > If that is not enough, we might do as Fedora does for openh264, that is > use the RPM Fusion infra for the SCM and building the package, but > upload it to another host. Given Pix mail from this morning, I guess it > could be where Livna was hosted. I wonder if in this case it might make most sense to just continue to use the established rpm.livna.org brand for stuff that is to hot even for RPM Fusion. People with upload access and signing keys are reading this list afaik. Guess that's why livna seems to have gotten fresh packages and support for current Fedora releases recently. Cu, knurd
Re: issue with zram module (better performace with compessing swap in ram)
On 31.07.2012 14:36, Nicolas Chauvet wrote: 2012/7/31 valent.turko...@gmail.com valent.turko...@gmail.com: Hi guys, I just found out that there is this awesome zram module for complessing swap in memory... Please report a bug in our bugzilla. Yeah, normally that the best -- but in this case it's not needed anymore, because it just got fixed (but remember, that was pure luck!) Cu knurd
Re: Livna down yet again
On 26.06.2012 11:12, Kevin Kofler wrote: Ken Dreyer wrote: Would it be acceptable if we kept the .spec file in RPM Fusion's CVS, but didn't host the actual tarball? I think we should just move the package to RPM Fusion Free and put Livna out of its misery. I don't see any actual legal action initiated against that package, so I don't think continuing to refuse carrying it is justified. The main reason why we didn't include it back then iirc was this (and note, it's a long story short description!): Some (two iirc) of the main contributors in the days before the merge mentioned they would not join RPM Fusion if it ships the package livna still provides these days. Some others (mainly those working for a big distributor) also mentioned it could be problematic for them. So it was a trade off between have the package in question in the repos and have more contributors back then. The later was important for the start of the project -- but these days it might be different, especially as those two I remember are not main contributors anymore. So even when Livna gets back shipping packages for f17, rhel6, ... it might be worth discussing the issue again, as I mentioned a few months ago already. Best way forward imho is someone sending a question like would you stop contributing to RPM Fusion if said package gets included to all contributors and then decide considering the answers and all the other available information. CU knurd
Re: Test needed - Was : NVIDIA driver and graphical grub2?
On 20.05.2012 15:06, Nicolas Chauvet wrote: With a fresh fedora 17 installation (RC1 and beyond) the grub2 graphical behaviour is enabled. I thought that was reverted in RC2? https://bugzilla.redhat.com/show_bug.cgi?id=822123 http://lists.fedoraproject.org/pipermail/test/2012-May/108179.html Or was I mislead somehow by the latter mail from Adam? Cu knurd
Re: Corner cases for -kmod-common packages
Philip Prindeville wrote on 26.01.2012 09:04: On 1/26/12 12:43 AM, Kevin Kofler wrote: Philip Prindeville wrote: [...] It's more of a tooling issue as I see it than an organizational requirement on how the .spec should be managed. I'd rather fix the tool than work around it. Then I'd say: Go and work towards fixing the tools and the tools and workflows behind it (when I was handling the pushes for RPM Fusion I sometimes removed old kmods by simply removing old SRPMs, then the push scripts removed all the compiled kmods -- with a scheme like your that would delete the common package, too). Until then I'd say the split is the easiest. CU knurd P.S.: And I'd say the kmod scheme has way bigger problems that might be worth addressing first. Just my point of view.
Re: kmods on rawhide
Ken Dreyer wrote on 02.01.2012 21:19: On Mon, Jan 2, 2012 at 12:49 PM, Nicolas Chauvet kwiz...@gmail.com wrote: 2012/1/2 Ken Dreyer ktdre...@ktdreyer.com: Do we need to bump rpms/buildsys-build-rpmfusion/devel/buildsys-build-rpmfusion-kerneldevpkgs-current ? Please have a look on Mini-Faq http://www.rpmfusion.org/Packaging/KernelModules/Kmods2 Thanks. I did read over the FAQ at that page before posting, but I was still curious, because I didn't see anything on that page to the effect that standard mock rebuilds on Rawhide are not supported for kmod packages. As it is, I'm just going to do a regular rpmbuild locally, against my own kernel-devel, instead of trying to use mock to automate the whole process. (I think that's what you meant by referring me to the FAQ?) I'm guessing that the buildsys-build-rpmfusion package only gets rev'd for kernels in Fedora releases, and not for Rawhide kernels? That's how it always has been done. But someone simply needs to do a diff like this and your problem should vanish, as kmodtool then should pick up the latest kernel that is available: http://cvs.rpmfusion.org/viewvc/rpms/buildsys-build-rpmfusion/devel/buildsys-build-rpmfusion-kerneldevpkgs-current?root=freer1=1.18r2=1.19view=patch Doing that in the RPM Fusion buildsys bears the risk that different builders or builds see different latest kernels. HTH CU knurd
Re: libdvdcss 1.2.11
On 03.12.2011 22:00, Xavier Bachelot wrote: It seems it's all been sorted out now, correct rpm versions are at the correct locations. However, I've noticed that out of all the currently supported distro releases, the F14 and EL5 builds are missing. Not a big deal for F14, but EL5 might be a nice addition. Even Remi doesn't have it in his EL5 repos afaics. Cu knurd
Re: libdvdcss 1.2.11
On 24.11.2011 14:28, Xavier Bachelot wrote: [...] Food for though, let's discuss. You didn't mention the IMHO two most important points. They are mentioned somewhere in the mailing list archives, but for the sake of the discussion I'll mention them quickly here: What influence will shipping libdvdcss in RPM Fusion have 1) on the contributor base 2) working together with other parties To give examples of what I mean. On 1): Some people might avoid contributing to RPM Fusion if libdvdcss is in the repos. I could for example imagine that having libdvdcss in the repos might be a problem for contributors that work for a Linux distributor we all know. But sure, other might like RPM Fusion more if it ships libdvdcss and start contributing. IOW: it's a trade off. On 2) It never happened, but I once had hoped somebody could work out a deal with Adobe to get permission to ship the flash-plugin in RPM Fusion. I'd imagine having libdvdcss in the free repo could be a problem when talking about such a deal with Adobe. Enough said Cu knurd
Re: rebuilds for kernel-2.6.41.1-1.fc15
On 23.11.2011 21:18, Adrian Reber wrote: On Wed, Nov 23, 2011 at 07:01:17PM +0100, Nicolas Chauvet wrote: On Tue, Nov 22, 2011 at 1:15 PM, Nicolas Chauvet kwiz...@gmail.com wrote: But note that this update is for the next kernels that were pushed in testing early this morning.. Can someone work on a script that bench which mirror are updated last ? I will ping on the next push to start such test. Does MirrorManager give this information? I Don't know... MirrorManager knows http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-released-15arch=x86_64; this should only return mirrors which are up to date. What is the exact meaning of up2date here. Is it in the sense they synced from download1.rpmfusion.org in the past _n_ hours, with _n_ being something like 24 or 48 hours? Cu knurd
Re: libdvdcss 1.2.11
Hi! On 21.11.2011 22:37, Xavier Bachelot wrote: On 11/21/2011 06:16 PM, Remi Collet wrote: Le 21/11/2011 17:15, Xavier Bachelot a écrit : After many years, there's a new release of libdvdcss. This raises the question of who does maintain this package these days. I've asked ANvil from livna.org, but it was not clear even to him, so I thought asking here might bring some light. This might be a bit off topic, but Livna instructs to mail rpmfusion-devel anyway. Check the remi repository ;) Yes, indeed, I've been pointed at your repo for libdvdcss already. But your repo provides much more than libdvdcss and most of the other stuff it provides is overlaping with other Fedora reporitories. Don't get me wrong, I know for sure you're doing a great work. My point is just that it's less convenient than repositories that stack up properly like Fedora + RPM Fusion + Livna. +1 I'm not looking at replacing the Livna repo with something else, I just want to make sure there is someone to maintain libdvdcss in Livna (or another place with a non-replacement policy). If there's no maintainer currently, I'll discuss further with Anvil on the way forward and I'm willing to step up to be the maintainer if needed. Maybe you'll want to step up too :-) I'm wondering if those involved and most active in RPM Fusion these days should first discuss if shipping libdvdcss in RPM Fusion might be the better solution... Cu knurd
Re: Need help with zfs kernel module.
On 19.10.2011 02:00, Richard Shaw wrote: On Tue, Oct 18, 2011 at 6:17 PM, Kevin Kofler kevin.kof...@chello.at wrote: Richard Shaw wrote: I have the spl kernel module building fine. The problem I'm having is that with upstreams method it also produces a -devel kernel module package that has headers and symbols needed for the zfs kernel module to build. I wonder if it wouldn't be easier to build the kmod from a single multi- tarball SRPM (and you'd have another SRPM with the same 2 tarballs for the -common portions, i.e. udev scripts, documentation etc.). Well, per my 2nd email, I've got a fix in place unless you see a problem with it? The main spl package contains the udev rules, init scripts, and available documentation so that's covered... The solution with two packages might get tricky to handle in the buildsys -- it's untested and maybe it simply works, but I doubt that. If I'd be you I'd put the spl stuff into the zfs package if nothing else in RPM Fusion uses it, as that makes everybody's life easier. Cu knurd
Re: kmods for video graphics
Kevin Kofler wrote on 18.10.2011 08:31: Sérgio Basto wrote: To much work or a common user don't know that. A common user, wants that updates be automatic. As these common users and I just use stable versions and use it on work. Normally, we don't have any trouble with any update. And this trouble is not easy to solve. First , know that computer don't boot and hangs on start X because missed kmod, and you need switch to VT , when it is possible ... A common user surely does NOT want to: * install a compiler toolchain, * install kernel development headers, * wait on system boot for the kernel module to compile and Especially on slow systems such as netbooks! * deal with any resulting errors, because some kernel API changed and the akmod was not updated for it. akmods are the wrong solution for the average user, binary kmods are the correct solution. Building software from source on the user's machine in a binary distribution is an ugly hack, not a solution for anything. But the current solution is still far from perfect and users way to often run into problems -- IOW, there is lot's of room for improvements. For example, we could have a small script or yum plugin that could get called on kernel install that could check the repos on the master server or the testing repos for matching kmod packages for example. That's not to hard, but I never got around to implement it/lost interest over time. CU knurd
Re: Heads up: Nicolas aka kwizart is the one that handles pushing now and I'm kind of gone
Hans de Goede wrote on 22.06.2011 08:42:
On 06/22/2011 12:19 AM, Julian Sikorski wrote:
W dniu 2011-06-21 09:26, Thorsten Leemhuis pisze:
Just FYI, way later than planed I finally handed over the pushing
responsibilities to Nicolas aka kwizart a few days ago.
As announced earlier(¹), the one and only thing I feel responsible for
in RPM Fusion from now on is staging-kmod{,-addons} (I orphaned all the
other packages I owned and won't do any further kmod rebuilds for new
kernels). In case you in the Future need help specifically from me
you'll find me over the usual ways, but I might not watch this list as
closely as I did in the past.
Good luck with RPM Fusion. I hope it gets better with me finally out of
the way.
Thanks for all the things you have done for RPM Fusion over the years!
+1
We've been really fortunate to have you around to keep rpmfusion running
all these years.
Thx, but just for the record: I for one think I did a bad job -- IMHO
there are way to many things wrong (not all of it is my fault, but some
things are) and I could not find the energy anymore to fix them myself.
I really hope that things get better with me out of the way now, as
Fedora really could benefit from a more healthy, better and stronger RPM
Fusion.
CU
knurd
Heads up: Nicolas aka kwizart is the one that handles pushing now and I'm kind of gone
Hi!
Just FYI, way later than planed I finally handed over the pushing
responsibilities to Nicolas aka kwizart a few days ago.
As announced earlier(¹), the one and only thing I feel responsible for
in RPM Fusion from now on is staging-kmod{,-addons} (I orphaned all the
other packages I owned and won't do any further kmod rebuilds for new
kernels). In case you in the Future need help specifically from me
you'll find me over the usual ways, but I might not watch this list as
closely as I did in the past.
Good luck with RPM Fusion. I hope it gets better with me finally out of
the way.
CU
knurd
(¹)
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2010-November/008851.html
Re: RPM Fusion (Fedora - nonfree) Package Build Report 2011-06-16
rpmfusion-pkgs-rep...@rpmfusion.org wrote on 16.06.2011 08:19: Packages built and released for RPM Fusion (Fedora - nonfree) testing/14: 4 [...] xorg-x11-drv-nvidia-275.09.07-1.fc14 Not true -- was pushed, but removed from the testing repos (maintainer requested that) before they were synced to the public, that's why the package is mentioned here. CU knurd
Re: musuruan is not in ACL for rpms/pushover/F-15
Richard Shaw wrote on 06.06.2011 20:13: On Mon, Jun 6, 2011 at 1:03 PM, Julian Sikorski beleg...@gmail.com wrote: I suspect the problem lays in the devel branch (it should be tagged _fc16). Can you have a look at this too? Thanks! You gonna have to make tag fiist against new dist. I have the same problem with sdlmame, the devel branch got tagged as fc15. My cvs checkout is as fresh as it gets. Is there anything that us packagers are supposed to do [...] Either do a fresh checkout or do update the common directory (which contains a file branches, which is where the makefile looks for the disttag). Cu knurd
Re: I removed a few packages from the devel/F15 repos due to broken deps
Hans de Goede wrote on 30.05.2011 15:19:
On 05/30/2011 01:26 PM, Hans de Goede wrote:
On 05/28/2011 08:29 PM, Thorsten Leemhuis wrote:
I was a bit rude earlier today and without any warning removed a few
packages from the devel repos (that just became the F15 release repos)
due to broken deps. See the list below for details; would be good if
anybody would tell the maintainers directly, but I don't care about RPM
Fusion enough these days to file bugs myself. Of course all of them can
simply be reintroduced by building a update.
snip
= Nonfree =
ec2-api-tools-1.4.2.4-1.fc15.src.rpm
frogatto-1.0.3-2.fc14.src.rpm
I've taken care of frogatto.
Hmm, this has not gone completely as planned, I set of a build
from devel, which got an fc15 tag rather then an fc16 tag, which
I noticed when I tried to actual do another build from the F-15
branch (which does have the same commits as devel now, but no tag
since that tag now exists on the devel branch).
Note the devel branch still getting an fc15 tag seems to be correct,
since the builder config for devel builds still points to f15 repos.
So we have a proper build for frogatto now, but it should end up
in both the F-15 and devel repo's not just the devel repo ...
That will happen.
Btw, Xavier handled all the changes on the Infra side and I assume he'll
update the builder configs to point to F16 over the next few days.
In case someone wonders what I did for the actual branching, here are
the rough steps:
* remove all kmod packages from the devel repos
* build a buildsys-build-rpmfusion package that contained a hard dep on
the F15 release kernel
* rebuild all kmods and make them build akmod packages, too
* check for broken deps and find a solution for them
* create a signing key for F16
* add the public key to the rpmfusion-{non,}free-release packages fopr
F13, F14 and F15
* build rpmfusion-{non,}free-release packages for F15 that have the
proper repos enabled and rawhide disabled
* push all of that
* for free and nonfree something like this:
mkdir releases/15/
cp -a development/ releases/15/Everything
* ask adrianr to make changes in the MirrorManager (in fact he asked me
before I asked him)
* build kmods for the updated kernel
CU
knurd
Re: I removed a few packages from the devel/F15 repos due to broken deps
Thorsten Leemhuis wrote on 30.05.2011 18:33: Hans de Goede wrote on 30.05.2011 15:19: On 05/30/2011 01:26 PM, Hans de Goede wrote: On 05/28/2011 08:29 PM, Thorsten Leemhuis wrote: That will happen. Btw, Xavier handled all the changes on the Infra side and I assume he'll update the builder configs to point to F16 over the next few days. Sorry, I was unprecise here. I should have written I assume that will happen; Xavier handled all the changes on the Infra side and I assume he'll handle this over the next few days, too. CU knurd
Re: I removed a few packages from the devel/F15 repos due to broken deps
Richard Shaw wrote on 30.05.2011 21:38:
On Mon, May 30, 2011 at 11:33 AM, Thorsten Leemhuis
fed...@leemhuis.info wrote:
In case someone wonders what I did for the actual branching, here are
the rough steps:
* remove all kmod packages from the devel repos
* build a buildsys-build-rpmfusion package that contained a hard dep on
the F15 release kernel
* rebuild all kmods and make them build akmod packages, too
* check for broken deps and find a solution for them
* create a signing key for F16
* add the public key to the rpmfusion-{non,}free-release packages fopr
F13, F14 and F15
* build rpmfusion-{non,}free-release packages for F15 that have the
proper repos enabled and rawhide disabled
* push all of that
* for free and nonfree something like this:
mkdir releases/15/
cp -a development/ releases/15/Everything
Actually it's
cp -al development/ releases/15/Everything
(Makes life for mirrors a whole lot easier)
* ask adrianr to make changes in the MirrorManager (in fact he asked me
before I asked him)
* build kmods for the updated kernel
And resigning the devel repo with the F16 key over the next few days:
I have created a rough wiki page[1] from this information to be
expounded upon. It will need to be made suitably version generic but I
didn't want this info to get lost.
I'm not sure what the right syntax is for code in the RPM Fusion
wiki, pre.../pre didn't work like it does on the Fedora wiki.
Richard
[1] http://rpmfusion.org/Branching
You might want to merge it into
http://www.rpmfusion.org/Infrastructure/PrepareRelease
CU
knurd
I removed a few packages from the devel/F15 repos due to broken deps
Hi!
I was a bit rude earlier today and without any warning removed a few
packages from the devel repos (that just became the F15 release repos)
due to broken deps. See the list below for details; would be good if
anybody would tell the maintainers directly, but I don't care about RPM
Fusion enough these days to file bugs myself. Of course all of them can
simply be reintroduced by building a update.
Cu
thl
= Free =
compat-{plone,zope,python24*} (not build in ages for devel)
autopano-sift-C-2.5.1-3.fc14.src.rpm
elisa-plugins-ugly-0.5.35-1.fc11.src.rpm
pragha-0.8.2-1.fc14.src.rpm
sonic-visualiser-freeworld-1.7.1-1.fc13.src.rpm
vdr-dxr3-0.2.10-3.fc14.src.rpm (depends on kmod-em8300 that doesn't
build for FC15)
west-chamber* xtables-addons* -- xtables-addons-kmod (required by
west-chamber) does not build in F15
open-vm-tools-kmod -- open-vm-tools does not build on F15
package: autopano-sift-C-2.5.1-3.fc14.x86_64 from rpmfusion-free-rawhide
unresolved deps:
libpano13.so.1()(64bit)
compat-python24-libxml2-2.7.6-1.fc12.x86_64 from rpmfusion-free-rawhide
unresolved deps:
libxml2 = 0:2.7.6
package: elisa-plugins-ugly-0.5.35-1.fc11.noarch from rpmfusion-free-rawhide
unresolved deps:
python(abi) = 0:2.6
package: pragha-0.8.2-1.fc14.x86_64 from rpmfusion-free-rawhide
unresolved deps:
libnotify.so.1()(64bit)
package: sonic-visualiser-freeworld-1.7.1-1.fc13.x86_64 from
rpmfusion-free-rawhide
unresolved deps:
liboggz.so.1()(64bit)
liblo.so.0()(64bit)
liboggz.so.1(liboggz.so.0.2)(64bit)
package: vdr-dxr3-0.2.10-3.fc14.x86_64 from rpmfusion-free-rawhide
unresolved deps:
em8300-kmod = 0:0.15.2
package: akmod-open-vm-tools-0.0.0.301124-2.fc15.x86_64 from
rpmfusion-free-rawhide
unresolved deps:
open-vm-tools-kmod-common = 0:0.0.0.301124
= Nonfree =
ec2-api-tools-1.4.2.4-1.fc15.src.rpm
frogatto-1.0.3-2.fc14.src.rpm
ogre-cg-1.6.1-4.fc12.src.rpm
pdflib-lite-7.0.5-1.fc14.src.rpm and
php-pecl-pdflib-2.1.8-1.fc14.src.rpm that depends on it
package: ec2-api-tools-1.4.2.4-1.fc15.noarch from rpmfusion-nonfree-rawhide
unresolved deps:
jaf
package: frogatto-1.0.3-2.fc14.x86_64 from rpmfusion-nonfree-rawhide
unresolved deps:
libboost_system-mt.so.1.44.0()(64bit)
libboost_regex-mt.so.1.44.0()(64bit)
package: ogre-cg-1.6.1-4.fc12.x86_64 from rpmfusion-nonfree-rawhide
unresolved deps:
libOgreMain-1.6.4.so()(64bit)
package: pdflib-lite-perl-7.0.5-1.fc14.x86_64 from rpmfusion-nonfree-rawhide
unresolved deps:
perl(:MODULE_COMPAT_5.10.1)
package: pdflib-lite-python-7.0.5-1.fc14.x86_64 from
rpmfusion-nonfree-rawhide
unresolved deps:
python(abi) = 0:2.6
Re: RPM Fusion (Fedora - free) Package Build Report 2011-04-28
On 29.04.2011 17:41, Richard Shaw wrote: On Fri, Apr 29, 2011 at 10:35 AM, Kevin Kofler kevin.kof...@chello.at wrote: Richard Shaw wrote: So we're going back to 0.5.x? Since even upgrading to 0.6.2 would require kdenlive to be rebuilt, right? We need a build of kdenlive against 0.6.2, then the whole thing can be pushed together. Ok, so we need to wait for Ryan to do that this weekend. I think he has finals at school or something right now. What is the status of this stuff? F14 testing has this afaics: 900857 Apr 11 18:20 mlt-0.7.0-2.fc14.src.rpm 25673134 Apr 14 09:15 openshot-1.3.0-3.fc14.src.rpm 3228349 Apr 22 14:54 kdenlive-0.7.8-2.fc14.src.rpm Can those be pushed to stable updates? Cu knurd
Re: RPM Fusion (Fedora - free) Package Build Report 2011-04-28
Kevin Kofler wrote on 29.04.2011 13:38: rpmfusion-pkgs-rep...@rpmfusion.org wrote: mlt-0.7.0-2.fc14 This mlt cannot be updated to because the kdenlive update that goes with it was not pushed. The currently stable kdenlive requires the old mlt soname. Did you just wanted to point out the fact or did you want anybody to do something to fix it? If the latter: If it involves pushing of packages directly to stable or things like that let me know, I'm still the only one with the paraphrases for the signing keys (¹). Cu knurd P.S.: /me wonders if anybody cares enough about RPM Fusion these to get the process of branching for F15 kicked off(²), there are just 3 1/2 weeks left before F15 gets released (¹) the plan is to hand them to Nicolas, but for various reasons that got delayed; I'm really sorry for that; Nicolas please poke me harder to hand them over once we are both back home (I'm at the Red Hat Summit next week and back on May 9th) (²) due to (¹) and the tight schedule for F15 I hereby commit myself to do the actually branching of the repos on the download servers for a last time; but someone from the infra team needs to update the builders, CVS and things like that in a coordinated fashion
Re: RPM Fusion (Fedora - free) Package Build Report 2011-04-28
Richard Shaw wrote on 29.04.2011 15:09: On Fri, Apr 29, 2011 at 6:59 AM, Thorsten Leemhuis fed...@leemhuis.info wrote: Kevin Kofler wrote on 29.04.2011 13:38: rpmfusion-pkgs-rep...@rpmfusion.org wrote: mlt-0.7.0-2.fc14 This mlt cannot be updated to because the kdenlive update that goes with it was not pushed. The currently stable kdenlive requires the old mlt soname. Did you just wanted to point out the fact or did you want anybody to do something to fix it? I was trying to but I don't yet have CVS access and Ryan can't do anything about it until this weekend. I grated you access to mlt in CVS -- seems that is the right thing to do here. Let me know if it doesn't work. My vote is still to downgrade to 0.6.2 (which would still be an upgrade from 0.5.x) which seems to work well (or least poorly) for Openshot and probably Kdenlive. That should give Ryan and I time to figure out if we need to wait for a 0.7.X point release or git version that fixes the playback issues. I don't want to decide things like that anymore these days. Maybe someone else here on the list wants. CU knurd
Re: RPM Fusion (Fedora - free) Package Build Report 2011-04-28
Kevin Kofler wrote on 29.04.2011 16:48: Thorsten Leemhuis wrote: Did you just wanted to point out the fact or did you want anybody to do something to fix it? If the latter: If it involves pushing of packages directly to stable or things like that let me know, I'm still the only one with the paraphrases for the signing keys (¹). I'd like that mlt update thrown out of stable until the maintainers have sorted things out, if possible. Moved it back to testing. CU knurd
Re: Zsnes is still in testing
Andrea Musuruane wrote on 26.04.2011 12:38: I'm the maintainer of zsnes. I just noticed that it is still in updates-testing for F14 (and maybe also other branches... I don't know how to check this) since nov 2010. Can someone please push it (and check also that other branches are pushed too)? Did you actually try to install it on a F14 system (sorry, I have none at hand to try myself quickly)? I back when the F14 repos got created moved all those packages to testing (and left them there since if they didn't get updated) that had broken deps. Cu knurd
Re: Dealing with the F-15 mass branch
On 13.02.2011 11:19, Hans de Goede wrote: Traditional we mass branch a lot later in rpmfusion then in Fedora and that is fine with me (less work). Just FYI for those that are not aware of the details: That traditional was more something like an historic accident (guess that describes it best in a few words) that happened due to time constrains (mainly on my side) and coordination problems. Cu knurd
Re: RPM Fusion (Fedora - free) Package Build Report 2011-02-13
On 13.02.2011 12:45, Nicolas Chauvet wrote: 2011/2/13 rpmfusion-pkgs-rep...@rpmfusion.org: ... Packages built and released for RPM Fusion (Fedora - free) 13: 1 xbmc-10.0-1.fc13.2 For the record, this package still doesn't fix the ABI breaks: This is a buildsys problem as reported here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=1619#c3 I've try to rebuild (again) the xbmc package. Note that the package pushed is a new build with a tag you created. And it should fix the problem afaics, as one of the buildlogs in http://buildsys.rpmfusion.org/build-status/job.psp?uid=9074 indicates that the new libmicrohttpd-devel was picked up. Cu knurd
Re: EL6 support in RPM Fusion buildsys ready
On 30.11.2010 20:20, Jack Neely wrote: But alas, I too have not received any guidance how, specifically, I can help. As I said, things like that are one of the reasons why I chose to take a break. Yes, I could go wild and hand out permissions to systems (I think I have access nearly everywhere), but we have a infrastructure lead that IMHO is supposed to coordinate things like that to avoid chaos :-/ Cu knurd
Re: EL6 support in RPM Fusion buildsys ready
On 30.11.2010 04:21, Jarod Wilson wrote: On Nov 28, 2010, at 11:16 AM, Thorsten Leemhuis wrote: On 28.11.2010 12:45, solarflow99 wrote: On Sun, Nov 28, 2010 at 3:18 AM, Thorsten Leemhuis fed...@leemhuis.info wrote: On 28.11.2010 11:51, solarflow99 wrote: On Sun, Nov 28, 2010 at 2:38 AM, Thorsten Leemhuis fed...@leemhuis.info wrote: Just FYI, building RPM Fusion packages for EL6 is possible now. Guess there will be a few rough edges here and there, so keep the eyes open and report any problems. oh good, do you know if we have an EL-5 build system? There's no rush, but I noticed my package in waiting status. Note that problems in our build infrastructure (like this) are one of the main reasons why I'm really unhappy about the state of RPM Fusion and want to have a break (see the other mail I just sent). This case for me boils down to: There are people that are supposed to take care about the build infrastructure and they are obviously not doing their work. Please ask them, not me, as I multiple times made clear that I don't want to do the administration of our build infra. In case you don't get satisfying results within a few days then ask me again please and I'll see what I can do to get a EL-5 builder running again. ok, and if there's something I can help you out with just let me know, rpmfusion has always been short staffed, so we have to do the best we can I suppose. I'm willing to help where I can. The direct problems at hand: The only x86 builder that is left has no local CentOS/RHEL mirror; the admin of this machine might be able to create one in the local net on the machine where other repos are mirrored. Screw it, why not. I'm rsync'ing down the CentOS 5.5 trees right now. /me makes a note to set up the builder this WE if nobody else indicates to do it Nb: the el6 trees on my builder are restricted to local access only, as they're true-blue (er, red?) RHEL6 GA trees. Noticed that. We should switch probably switch to CentOS 6 once its available. Also, the configs will likely also need to point at the optional trees to pick up an array of additional BuildReqs for a lot of things. I did only configure the Workstation and the server tree for now and thought we can take care of the other stuff once it's needed. But yes, CentOS6 is likely the best in the long term. [...] CU knurd
EL6 support in RPM Fusion buildsys ready
Hi! Just FYI, building RPM Fusion packages for EL6 is possible now. Guess there will be a few rough edges here and there, so keep the eyes open and report any problems. Cu knurd
Taking a break (this time for real) and looking for volunteers that take over my RPM Fusion jobs
Hi! Quoting from: http://article.gmane.org/gmane.linux.redhat.fedora.rpmfusion.devel/7034/ [...] Think of it a bit like Thorsten will be leaving us by start of the summer (to be clear: summer in the northern hemisphere of 2010 ;-) ) and he only does those things from now on that he really has to do to keep RPM Fusion running, as there is no replacement (yet). [...] Seems that was not enough of a warning, as I didn't get any work of my shoulders. I nevertheless stayed half a year longer and did some work to make sure RPM Fusion for F14 was ready. But I don't want to continue like this, as those jobs feel like a burdon and I think I did a bad job in the past few months (in some areas that was on purpose in the hope that someone would get annoyed enough and step up to take over that work). Hence I hereby announce that I plan to orphan most of my packages (all except for staging-kmod) in RPM Fusion and stop all the regular work by the end of this year(¹). That includes * pushes * kmod rebuilds IOW: If you care about RPM Fusion and want it to continue to exist step up and take care of things, as I took care of some crucial things and there is no backup in place right now that will silently take over those jobs once I stop doing them. CU knurd P.S.: I won't vanish completely and will be available to answer questions by mail; make sure to sent mails directly to me (or CC me on ML post) if you specifically need my help (¹) I might take some packages back after a few months if nobody picks them up and if I feel like it. The latter mainly depends on how things evolve in RPM Fusion; if it becomes a real healthy project (which I really hope) with a proper organization and working and healthy (computer) infrastructure then I'll likely get more involved again in the long term;
Re: EL6 support in RPM Fusion buildsys ready
On 28.11.2010 11:51, solarflow99 wrote: On Sun, Nov 28, 2010 at 2:38 AM, Thorsten Leemhuis fed...@leemhuis.info wrote: Just FYI, building RPM Fusion packages for EL6 is possible now. Guess there will be a few rough edges here and there, so keep the eyes open and report any problems. oh good, do you know if we have an EL-5 build system? There's no rush, but I noticed my package in waiting status. Note that problems in our build infrastructure (like this) are one of the main reasons why I'm really unhappy about the state of RPM Fusion and want to have a break (see the other mail I just sent). This case for me boils down to: There are people that are supposed to take care about the build infrastructure and they are obviously not doing their work. Please ask them, not me, as I multiple times made clear that I don't want to do the administration of our build infra. In case you don't get satisfying results within a few days then ask me again please and I'll see what I can do to get a EL-5 builder running again. Cu knurd
Re: EL6 support in RPM Fusion buildsys ready
On 28.11.2010 12:45, solarflow99 wrote: On Sun, Nov 28, 2010 at 3:18 AM, Thorsten Leemhuis fed...@leemhuis.info wrote: On 28.11.2010 11:51, solarflow99 wrote: On Sun, Nov 28, 2010 at 2:38 AM, Thorsten Leemhuis fed...@leemhuis.info wrote: Just FYI, building RPM Fusion packages for EL6 is possible now. Guess there will be a few rough edges here and there, so keep the eyes open and report any problems. oh good, do you know if we have an EL-5 build system? There's no rush, but I noticed my package in waiting status. Note that problems in our build infrastructure (like this) are one of the main reasons why I'm really unhappy about the state of RPM Fusion and want to have a break (see the other mail I just sent). This case for me boils down to: There are people that are supposed to take care about the build infrastructure and they are obviously not doing their work. Please ask them, not me, as I multiple times made clear that I don't want to do the administration of our build infra. In case you don't get satisfying results within a few days then ask me again please and I'll see what I can do to get a EL-5 builder running again. ok, and if there's something I can help you out with just let me know, rpmfusion has always been short staffed, so we have to do the best we can I suppose. I'm willing to help where I can. The direct problems at hand: The only x86 builder that is left has no local CentOS/RHEL mirror; the admin of this machine might be able to create one in the local net on the machine where other repos are mirrored. Then all what is needed is creating a few config files, which can be done in ~15 minutes or so. I can do that, but as I indicated already: I'd say it's the job of our infra group and would prefer to hear from them first before I once again step on their toes and do their work (which I often did in the past and which might be more harmful then helpful; don't know) Some of the overall RPM Fusion problem we are facing in this area: * where did the other x86 builders we had go? Seems they simply got lost over time * you and others iirc applied to help with infra work earlier; why haven't you got access and/or instructions? * seems there is not much interest in the el5 repo; some packages were build, but nobody really cared and for a lot of people it seems the el5 branch was fire once and forget (part of the problem: ownership/responsibilities were not clearly solved and owners.list for el is wrong in some places); that's one of the reasons why I left all the packages in testing CU knurd
Re: Taking a break (this time for real) and looking for volunteers that take over my RPM Fusion jobs
On 28.11.2010 12:26, Hans de Goede wrote: On 11/28/2010 12:09 PM, Thorsten Leemhuis wrote: Quoting from: http://article.gmane.org/gmane.linux.redhat.fedora.rpmfusion.devel/7034/ [...] Hence I hereby announce that I plan to orphan most of my packages (all except for staging-kmod) in RPM Fusion and stop all the regular work by the end of this year(¹). That includes [...] I'm sorry to see you leave (*), I'm unsure myself if it's leaving, a (extended?) break, or a heavy reduction in my involvement. As I said, it depends partly on how things evolve. I also think I forgot to make something clear: I think there were two options for me: (a) invest a lot of time and try to get RPM Fusion good to be happy with it again (b) get out of the way, which might get ugly for RPM Fusion and Fedora users in the short term, but hopefully leads to something better in the long term when people notice how understaffed RPM Fusion is and begin to help It was pretty clear to me that b is the better option, as I lack time right now to do a successfully. Further: Fedora in some areas seems to move in a direction it don't like much (the updates policy for example; lack of vision/direction another; and the continued unwillingness to cooperate with RPM Fusion or similar repos to make Fedora as easy to use as for example Ubuntu is), so I not sure if spending time on Fedora is worth it. But I could maybe take over some of the packages you're orphaning. I was about to ask for a list, but I realized I could do that myself, so for all on the list here are Thorsten's packages in rpmfusion-free (according to owners.list): [...] rt2860 That a mistake in owners.list, oget owns this one (and all the other packages with drivers from Ralink) CU knurd
Re: Packages needing rebuild for libao-1.0.0
On 10.10.2010 20:22, Julian Sikorski wrote: W dniu 10.10.2010 16:55, Mamoru Tasaka pisze: (by the way, while bsnes-0.051 exists on nonfree, bsnes-0.070 also exists on free?) bsnes is free now, if it still shows up in nonfree this is a mistake. Thorsten? Will vanish with the next push. CU knurd
Re: RPM Fusion (Fedora - free) Package Build Report 2010-09-21
rpmfusion-pkgs-rep...@rpmfusion.org wrote on 21.09.2010 10:27: Packages built and released for RPM Fusion (Fedora - free) 12: 19 ffmpeg-0.6-3.fc12 NEW libva-freeworld-0.31.1-1.sds4.fc12 : Video Acceleration (VA) API for Linux FYI: This was a error I reverted. BTW, @Nicolas: When can those finally get moved out of testing? They are there for weeks now... CU knurd
Re: problem uploading file
Karel Volný wrote on 14.09.2010 15:56: I'm finished with ufo-ai update, but I'm unable to upload the new data package as I'm getting server error: [kvo...@kvolny devel]$ make new-sources FILES=ufoai-2.3- data.tar Checking : ufoai-2.3-data.tar on https://cvs.rpmfusion.org/repo/pkgs/upload.cgi... Uploading: ufoai-2.3-data.tar to https://cvs.rpmfusion.org/repo/pkgs/upload.cgi... curl: (22) The requested URL returned error: 500 make: *** [new-sources] Error 1 can someone please take a look at it? A bug or a mail to http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-sysadmin seems to work better to get the attention of the sysadmins. I do not consider myself one of them, but I fixed this, as I saw the new ufoai without the new data package in the push queue and thought it might be better to get this fixed rather sooner than later. So: - if the file needs to be placed into the lookaside cache by hand, it is this one: http://sourceforge.net/projects/ufoai/files/UFO_AI 2.x/2.3/ufoai-2.3-data.tar (md5 08fa6d5c80231468c4d5e886600c8dcf) Manually uploaded. Never done this manually before, if it doesn't work let me know. CU knurd
Re: Missing buildsys-build?
On 10.09.2010 19:27, Jack Neely wrote:
Folks,
I can't find this version of buildsys-build and am therefore having
trouble building kmods. The last version I see on the mirrors is
10:buildsys-build-rpmfusion-13-10
which is dated Augs 29th.
Where might this be?
It afaics got stuck on the way from the internal master server to the
public server. It's available now.
Cu
thl
On Wed, Sep 08, 2010 at 05:17:20PM +0200, Thorsten Leemhuis wrote:
Author: thl
Update of /cvs/free/rpms/buildsys-build-rpmfusion/F-13
In directory se02.es.rpmfusion.net:/tmp/cvs-serv3422
Modified Files:
buildsys-build-rpmfusion-kerneldevpkgs-current
buildsys-build-rpmfusion.spec
Log Message:
* Wed Sep 08 2010 Thorsten Leemhuis fedora [AT] leemhuis [DOT] info -
10:13-11
- rebuild for kernel 2.6.34.6-54.fc13
Index: buildsys-build-rpmfusion-kerneldevpkgs-current
===
RCS file:
/cvs/free/rpms/buildsys-build-rpmfusion/F-13/buildsys-build-rpmfusion-kerneldevpkgs-current,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- buildsys-build-rpmfusion-kerneldevpkgs-current 27 Aug 2010 20:54:11
- 1.31
+++ buildsys-build-rpmfusion-kerneldevpkgs-current 8 Sep 2010 15:17:15
- 1.32
@@ -1,3 +1,3 @@
-2.6.34.6-47.fc13
-2.6.34.6-47.fc13smp
-2.6.34.6-47.fc13PAE
+2.6.34.6-54.fc13
+2.6.34.6-54.fc13smp
+2.6.34.6-54.fc13PAE
Index: buildsys-build-rpmfusion.spec
===
RCS file:
/cvs/free/rpms/buildsys-build-rpmfusion/F-13/buildsys-build-rpmfusion.spec,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- buildsys-build-rpmfusion.spec27 Aug 2010 20:54:11 - 1.40
+++ buildsys-build-rpmfusion.spec8 Sep 2010 15:17:15 - 1.41
@@ -3,7 +3,7 @@
Name: buildsys-build-%{repo}
Epoch: 10
Version:13
-Release:10
+Release:11
Summary:Tools and files used by the %{repo} buildsys
Group: Development/Tools
@@ -86,6 +86,9 @@
%changelog
+* Wed Sep 08 2010 Thorsten Leemhuis fedora [AT] leemhuis [DOT] info -
10:13-11
+- rebuild for kernel 2.6.34.6-54.fc13
+
* Fri Aug 27 2010 Thorsten Leemhuis fedora [AT] leemhuis [DOT] info -
10:13-10
- rebuild for kernel 2.6.34.6-47.fc13
Re: another issue with builder.wilsonet.com: repodata not found
Jarod Wilson wrote on 03.08.2010 15:58: On Sun, Aug 1, 2010 at 6:41 PM, Julian Sikorski beleg...@gmail.com wrote: [...] Yeah, looks like I neglected to update the f13 base path after release... :o. Its all better now. I've started putting together f14 mock configs as well. Hint: You know there are scripts in CVS that help with creating sane mock configs for the builders? But I don't know if all the infrastructure guys know about them or use something else these days. Cu knurd
Re: How to remove a package (iscsi-target) from rpmfusion
Hans de Goede wrote on 02.07.2010 08:15: I would like to see iscsi-target removed from rpmfusion as upstream is dead, it breaks compiling with every other kernel release, and sometimes breaks silently with a new kernel release. As I'm no longer using it myself, and thus not actively maintaining it I think it is best to simply remove this package from rpmfusion. Basically as in Fedora iirc and afaics; see also https://bugzilla.rpmfusion.org/show_bug.cgi?id=963#c4 Regarding the removal from the repos: We just as Fedora normally don't remove packages from the release repos. It is possible if there is a strong reason, there is just some amount of manual work involved which I'd like to avoid because manual often leads to things breaking -- and less free time for me ;-) CU knurd
Re: rpm.livna.org
On 02.07.2010 20:29, Itamar Reis Peixoto wrote: On Fri, Jul 2, 2010 at 2:49 PM, Stewart Adam maill...@diffingo.com wrote: There's been a few posts on the forums asking what is happening to rpm.livna.org, looks like the DNS settings weren't fixed (it currently redirects to http://images.crazyfrogs.org/main.php). Was our copy of the Livna repo lost in the HDD failure? All I know is this (from #rpmfusion) [07:56:19]knurd_afk | Pix, any idea why rpm.livna.org is down? [15:35:52] Pix | knurd_afk: yeah, benden is coming online slowly [15:36:09] Pix | i recovered the hdd, i'm slowing uploading files to the new benden on a dsl line :) livna is now rpmfusion No, it's not, there is still one package that some (not all; it's still a controversial topic) people (including me) preferred not to have in RPM Fusion. Cu knurd
Re: Heads up: xine-lib update for F12 headed for stable, will need xine-lib-extras-freeworld push in sync
Kevin Kofler wrote on 29.06.2010 16:51: an update of xine-lib on Fedora 12 to 1.1.18.1, the version already in Fedora 13 and fixing several bugs in the previous F12 version (1.1.16.3), currently in updates-testing, is now being queued for stable. A matching xine-lib-extras-freeworld (xine-lib-extras-freeworld-1.1.18.1-1.fc12) is already in RPM Fusion Free testing for F12 and will have to be pushed in sync to avoid broken dependencies. The push seems to be in progress on the Fedora side; I'm preparing the push of xine-lib-extras-freeworld-1.1.18.1-1.fc12 to stable right now and will actually push it out in parallel with the Fedora push of the new xine-lib or before I leave the keyboard for a longer period of time this evening. Cu knurd
Re: rpms/xorg-x11-drv-nvidia/F-11 .cvsignore, 1.18, 1.19 blacklist-nouveau.conf, 1.1, 1.2 nvidia-config-display, 1.1, 1.2 sources, 1.19, 1.20 xorg-x11-drv-nvidia.spec, 1.35, 1.36
Dominik 'Rathann' Mierzejewski wrote on 21.06.2010 14:47: On Monday, 21 June 2010 at 12:29, Nicolas Chauvet wrote: Author: kwizart Update of /cvs/nonfree/rpms/xorg-x11-drv-nvidia/F-11 In directory se02.es.rpmfusion.net:/tmp/cvs-serv22695/F-11 Modified Files: .cvsignore blacklist-nouveau.conf nvidia-config-display sources xorg-x11-drv-nvidia.spec Log Message: Update to 195.36.31 [...] Index: blacklist-nouveau.conf === RCS file: /cvs/nonfree/rpms/xorg-x11-drv-nvidia/F-11/blacklist-nouveau.conf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- blacklist-nouveau.conf 1 Jul 2009 16:59:27 - 1.1 +++ blacklist-nouveau.conf 21 Jun 2010 10:29:31 - 1.2 @@ -1,4 +1,4 @@ # RPM Fusion blacklist for nouveau driver - you need to run as root: -# mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r) +# dracut -f /boot/initramfs-$(uname -r).img $(uname -r) # if nouveau is loaded despite this file. blacklist nouveau Huh? Last F-11 kernel uses mkinitrd, not dracut. Fedora 11 never switched to dracut as far as I know. In addition: F-11 will be EOL in less than a week iirc, so is it really worth to update the driver? CU thl
Re: RPM Fusion (Fedora - free) Package Build Report 2010-05-31
On 31.05.2010 21:36, rpmfusion-pkgs-rep...@rpmfusion.org wrote: Packages built and released for RPM Fusion (Fedora - free) 13: 2 [...] xtables-addons-kmod-1.27-1.fc13 xtables-addons-kmod-1.27 in fact was not moved to stable -- that was a mistake of mine I noticed right when it happened and I moved the package back to testing. Sorry for the trouble. CU knurd
Re: RPM Fusion (Fedora - free) Package Build Report 2010-05-31
On 31.05.2010 21:47, Orcan Ogetbil wrote: On Mon, May 31, 2010 at 3:24 PM, rpmfusion-pkgs-rep...@rpmfusion.org wrote: Changes in RPM Fusion (Fedora - free) testing/13: rt2870-2.1.2.0-2.fc13.1 --- * Fri Dec 04 2009 Orcan Ogetbil oget [DOT] fedora [AT] gmail [DOT] com - 2.1.2.0-2.1 - Blacklist kernel's rt2800usb module rt3070-2.1.1.0-3.fc13.1 --- * Fri Dec 04 2009 Orcan Ogetbil oget [DOT] fedora [AT] gmail [DOT] com - 2.1.1.0-3.1 - Blacklist kernel's rt2800usb module Can we get these pushed to stable ASAP? The same packages have been tested and are in use on F-12 since December. Otherwise the wireless will be broken for F-13 rt2870/rt3070 users who don't know about blacklisting kernel modules. I forgot to submit these to F-13 in time.
Re: RPM Fusion (Fedora - free) Package Build Report 2010-05-31
(second try, sorry, well know keyboard error that happens now and then on this machine) On 31.05.2010 21:47, Orcan Ogetbil wrote: On Mon, May 31, 2010 at 3:24 PM, rpmfusion-pkgs-rep...@rpmfusion.org wrote: Changes in RPM Fusion (Fedora - free) testing/13: rt2870-2.1.2.0-2.fc13.1 --- * Fri Dec 04 2009 Orcan Ogetbil oget [DOT] fedora [AT] gmail [DOT] com - 2.1.2.0-2.1 - Blacklist kernel's rt2800usb module rt3070-2.1.1.0-3.fc13.1 --- * Fri Dec 04 2009 Orcan Ogetbil oget [DOT] fedora [AT] gmail [DOT] com - 2.1.1.0-3.1 - Blacklist kernel's rt2800usb module Can we get these pushed to stable ASAP? The same packages have been tested and are in use on F-12 since December. Otherwise the wireless will be broken for F-13 rt2870/rt3070 users who don't know about blacklisting kernel modules. I forgot to submit these to F-13 in time. Push in progress, even if I tend to think that it might be wise to have even updates like this out for testing for 1 or 2 days. CU knurd
Re: Questions about cairo-dock build and push request
Hi! On 29.05.2010 17:33, Mamoru Tasaka wrote: As libetpan 1.0 was pushed into F-12/13 updates (on Fedora side) and these updates contain library soname change, I rebuilt cairo-dock on rpmfusion12/13. Then, first of all: http://buildsys.rpmfusion.org/build-status/job.psp?uid=7297 http://buildsys.rpmfusion.org/logs/fedora-13-rpmfusion_free/7297-cairo-dock-2.1.3.9-2.fc13/ Why does this build pull some packages from F13updates-testing? Because it ages ago was decided to enable updates-testing in the buildroots (should be in the archives of this list) and it likely got not well documented like thousands of other things in RPM Fusion land. Feel free to rediscuss that. [...] Can these packages skip -testing stage and be pushed into -stable updates directly? Push in progress. CU knurd
Re: Any remaining things to be done before the final F13 release repos can get created?
Hans de Goede wrote on 25.05.2010 12:13: On 05/25/2010 12:04 PM, Hans de Goede wrote: On 05/18/2010 11:29 AM, Thorsten Leemhuis wrote: snip and a new smc package (looking at you Hans! the current one has unsatisfied deps in case you are not aware) I thought I already see you do a rebuild for this? I'll look into this right away. Ok further reading the thread and looking at the .spec I see you did a rebuilt no May 16, and now another one, with patches added. Thx for taking care of this. Note that next time you want to reach me, pinging on irc, Sorry, I was still under the assumption you are only occationally on IRC. or a direct mail That's why you were CCed on two of the mail in this thread ;-) Maybe your filters catched them as well? or filing a bug That one of my faults, I sometimes feel so tired of bugzilla and maintainers not catching up that I don't want to deal with bugzilla to much. Anyways thanks for taking care of this. I do notice that you've only made changes to F-13 branch I'll forward port them to the devel branch, And a proper fix (like Kevin suggested) for my hack might be a good idea. CU knurd
Re: Any remaining things to be done before the final F13 release repos can get created?
On 19.05.2010 07:20, Michael Schwendt wrote: On Wed, 19 May 2010 07:03:38 +0200, Kevin wrote: cairo-dock will need a rebuild for the new libetpan in F13 updates-testing That should be done in updates, not in the release repo. The release repo should match F13 GA, not post-release updates. Sure, ... I thought RPM Fusion has a way to build against updates-testing, but I was mistaken. It's possible -- just tell me what you need in the buildroot and I'll put it there. Sure, that creates delays and is not really ideal, but works (and kind of similar to the manual buildroot overrides in Fedora iirc...) CU knurd
Re: Any remaining things to be done before the final F13 release repos can get created?
On 19.05.2010 07:20, Kevin Kofler wrote: Thorsten Leemhuis wrote: (¹) I sill hope for two fixes: A updated VirtualBox-OSE-kmod package https://bugzilla.rpmfusion.org/show_bug.cgi?id=1216 and a new smc package (looking at you Hans! the current one has unsatisfied deps in case you are not aware) This patch should fix smc to build: http://repo.calcforge.org/temp/smc-1.9-fix-implicit-linking.patch You'll also have to BR libX11-devel. Many thanks for that. Some more was needed (disclaimer: including a hack to fix another DSO problem), but then it built Push ion progress. Cu knurd
Re: RFC: Method for packaging game data (was Re: Non-commercial redistributable game data)
On 23.05.2010 14:06, Jonathan Dieter wrote: I've been looking at uqm today to see how we could do this. I did come up with one method that does work (at least in Fedora 13), though it will be a bit of a pain for autodownloader. For uqm, it looks something like this: uqm is in Fedora autodownloader is in Fedora uqm-content is in RPM Fusion Remove Requires: autodownloader from uqm Add Requires: uqm(data) to uqm Add Provides: uqm(data) to autodownloader Add Provides: uqm(data) to uqm-content When installing uqm, if RPM Fusion isn't enabled, autodownloader gets downloaded and installed, and then the game data gets downloaded the first time uqm is run. If RPM Fusion is enabled, yum will prefer uqm-content, which mean uqm will run the first time without needing to download anything. This should consistently work because, in the newer yum versions, one of the tests for choosing which package to install as a dependency is to compare how many letters match (i.e. uqm and uqm-content both start with uqm, while autodownloader doesn't, so uqm-content would be preferred over autodownloader). [...] Sounds fragile to me. I'd ask the main yum guys for their option before going that route further. Cu knurd
Re: Broken deps - RPM Fusion free Fedora 12 - 2010-04-30
On 05.05.2010 15:43, David Woodhouse wrote: On Fri, 2010-04-30 at 13:47 +0200, Thorsten Leemhuis wrote: Michael Schwendt wrote on 30.04.2010 13:10: On Fri, 30 Apr 2010 18:02:07 +0800 (CST), Chen wrote: All ppc(64) Broken deps are caused by https://bugzilla.rpmfusion.org/show_bug.cgi?id=1166, I think it already fixed days ago. Thanks for the pointer. BTW, he pointed to it a few days ago when we discussed the ppc problem already (it iirc was a mail from Dominik about a mplayer build problem; the root of that problem was exactly the same) Not responding to that ticket is exactly one thing that should not happen. I understand that some people hate Plague [for sometimes dubious reasons], but undermining it with lack of support is just rude. Just FYI, I still try to stay away from infra work, but if there is something help from my side is needed please ping me (maybe I'm the only one that has access to the ppc builder -- there was the plan to switch to a different one months (a year?) ago and give others from RPM Fusion access to it, but that work stalled). There's certainly no reason why Michael shouldn't have access to the existing build machine, regardless of any plan to migrate to a different machine. I didn't mean to imply that. But whatever: Xavier is the one that needs access -- Michael is not involved in the infra group (he IMHO of course could get access to both if he wanted to). CU knurd
Any remaining things to be done before the final F13 release repos can get created?
Hi! Just a heads up: I plan to create the final F13 release repos over the next few days by basically moving everything from the updates repos to the Everything repos(¹). If you want a updated package in there please tell me until Thursday evening, otherwise it might be to late. Cu thl (¹) I sill hope for two fixes: A updated VirtualBox-OSE-kmod package https://bugzilla.rpmfusion.org/show_bug.cgi?id=1216 and a new smc package (looking at you Hans! the current one has unsatisfied deps in case you are not aware)
Re: Any remaining things to be done before the final F13 release repos can get created?
Ralf Corsepius wrote on 18.05.2010 11:32: On 05/18/2010 11:29 AM, Thorsten Leemhuis wrote: Just a heads up: I plan to create the final F13 release repos over the next few days by basically moving everything from the updates repos to the Everything repos(¹). If you want a updated package in there please tell me until Thursday evening, otherwise it might be to late. free updates carries several *.fc14.rpms. /me knew he had forgotten something Rebuilds queued, thx for the reminder. CU knurd
Re: rpmfusion-release
On 16.05.2010 14:38, Dominik 'Rathann' Mierzejewski wrote: On Saturday, 15 May 2010 at 00:32, Rahul Sundaram wrote: If we build such a release package within Livna, maybe we can enable all three together. There's no Livna for recent Fedora releases. Which means there's no easy way for end-users to get libdvdcss in F-12, for example. I haven't tried myself, but multiple people told me livna still works fine for F12 and F13. Cu knurd
Re: Non-commercial redistributable game data
On 12.05.2010 19:25, Jonathan Dieter wrote: I've noticed a number of games whose content is distributable as long as it's distributed for free. A few of those games have ended up in Fedora but use autodownloader to download the game data. I really don't like this method because, at least as I understand it, the game data ends up in the user's home directory. If another user wants to play the game, they have to redownload the data. What is the feasibility of providing -data packages in rpmfusion-nonfree that would provide the data for said games, so the data could be installed system-wide? [...] Sure, why not? It would just be good if all everything is taken care of to prevent users from running into trouble if they use or have used autodownloader, but you obviously are thinking about that already. Cu knurd
Re: Drop vboxgtk
On 29.04.2010 11:56, Hicham Haouari wrote: I want to drop vboxgtk from rpmfusion because : - It is dead upstream - VirtualBox API changed from 3.0.x to 3.1.x causing vboxgtk to be non-functional. Please tell me which procedures I should follow Remove the files from cvs and put a dead.package file there instead -- that's just the same you'd do in Fedora iirc and did already iirc. The packages also needs to be removed from some of the repos -- devel and F13 I assume? CU knurd
Re: Broken deps - RPM Fusion free Fedora 12 - 2010-04-30
Michael Schwendt wrote on 30.04.2010 13:10: On Fri, 30 Apr 2010 18:02:07 +0800 (CST), Chen wrote: All ppc(64) Broken deps are caused by https://bugzilla.rpmfusion.org/show_bug.cgi?id=1166, I think it already fixed days ago. Thanks for the pointer. BTW, he pointed to it a few days ago when we discussed the ppc problem already (it iirc was a mail from Dominik about a mplayer build problem; the root of that problem was exactly the same) Not responding to that ticket is exactly one thing that should not happen. I understand that some people hate Plague [for sometimes dubious reasons], but undermining it with lack of support is just rude. Just FYI, I still try to stay away from infra work, but if there is something help from my side is needed please ping me (maybe I'm the only one that has access to the ppc builder -- there was the plan to switch to a different one months (a year?) ago and give others from RPM Fusion access to it, but that work stalled). And as brought up a few days ago already: Xavier or others from the sysadmin team, is there anything that changed recently that might be the reason for this problem? Are the Plague config files for ppc and ppc64 available in some public place? I maintained those in CVS (cvs.rpmfusion.org, /cvs/rpmfusion/), but you might need a RPM Fusion FAS-Account to be able to access them. And the sysadmins now use puppet for some services, so those files might not be up2date in cvs. Download failures not killing the build job would only occur for testing targets, but none of RPM Fusions targets should be set up like that. Also, please save a copy of the server and builder logs. /me will do that later and sent the config by private mail when back home from work /me will then also look into the multilib problem for the testing repos CU knurd
Re: rpmfusion and no frozen rawhide
Thorsten Leemhuis wrote on 27.04.2010 14:56: Thorsten Leemhuis wrote on 27.04.2010 14:42: Adam Williamson wrote on 27.04.2010 14:11: On Tue, 2010-04-27 at 13:05 +0100, Adam Williamson wrote: Okay, so I used the link for 10, 11, 12 and that almost works, except that it gets the GPG key stuff wrong: GPG key retrieval failed: [Errno 14] Could not open/read file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-13-x86_64 I have to use --nogpgcheck with yum, can't install things with PackageKit. Sorry for the conversation with myself :) it seems that it initially installed rpmfusion-free-release-10-5.noarch , with rpmfusion-free-release-13-1.noarch available as an update (but PK refuses to update it because of the key issue). If I update to 13-1 with yum --nogpgcheck, the GPG key file now shows up. That's basically how it's supposed to work except for the nogpgcheck -- that problem should vanish once I move the latest rpmfusion-free-release from updates-testing to updates /me wanders of to do that Looks like it will take a little longer as one packages that is needed was not build for some reason. Everything in place now. A simple rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm on any freshly installed Fedora 11, 12 or 13 will do the right thing now. Yes, the release packages will get updated on the first run on F12 and F13, but the above packages have all the required keys, so everything should work smoothly CU knurd
Re: rpmfusion and no frozen rawhide
Adam Williamson wrote on 26.04.2010 21:06: [...] I don't know if the actual Fusion packages are built against F14 but labelled F13, but if they are that's a very big problem and we really shouldn't do it. Anything built against Fedora's Rawhide repo is for Fedora 14 and should be labelled .fc14, not .fc13. There iirc was a small window when rawhide branched when F13 builds where done using rawhide. Xavier changed it back then and I did a lot of other adjustments in the past weeks, so everything should be sane now (and mostly was duing all that time; yes, that's the long story short, but there is nothing to worry about afaics). The only remaining thing that need fixing is a rebuild for those packages that were build against rawhide and contain fc14 in their name. (libmms, gnome-mplayer, gecko-mediaplayer). That's on my todo list. BTW, in you blog post you wrote There’s a secondary problem with F13, which is that as far as RPM Fusion is concerned, F13 doesn’t seem to exist. That's incorrect. Everything is on the servers, but the 13 repo is not under development/13 -- instead there is an empty one in the final place and everything is in the updates and updates-testing repos for now, as that's easier to handle with our push scripts. CU knurd
Re: builder.wilsonet.com hangs?
Chen Lei wrote on 27.04.2010 04:04: I cannot build any packages on plague since yesterday. Anyone can help me? Thank you. There is a problem that is not simply fixed; I will need to talk to the one that hosts the builder before things can move on again. Please be patient, sorry for the trouble. CU knurd
Re: rpmfusion and no frozen rawhide
Adam Williamson wrote on 27.04.2010 14:11: On Tue, 2010-04-27 at 13:05 +0100, Adam Williamson wrote: Okay, so I used the link for 10, 11, 12 and that almost works, except that it gets the GPG key stuff wrong: GPG key retrieval failed: [Errno 14] Could not open/read file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-13-x86_64 I have to use --nogpgcheck with yum, can't install things with PackageKit. Sorry for the conversation with myself :) it seems that it initially installed rpmfusion-free-release-10-5.noarch , with rpmfusion-free-release-13-1.noarch available as an update (but PK refuses to update it because of the key issue). If I update to 13-1 with yum --nogpgcheck, the GPG key file now shows up. That's basically how it's supposed to work except for the nogpgcheck -- that problem should vanish once I move the latest rpmfusion-free-release from updates-testing to updates /me wanders of to do that Cu knurd
Re: rpmfusion and no frozen rawhide
Thorsten Leemhuis wrote on 27.04.2010 14:42: Adam Williamson wrote on 27.04.2010 14:11: On Tue, 2010-04-27 at 13:05 +0100, Adam Williamson wrote: Okay, so I used the link for 10, 11, 12 and that almost works, except that it gets the GPG key stuff wrong: GPG key retrieval failed: [Errno 14] Could not open/read file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-13-x86_64 I have to use --nogpgcheck with yum, can't install things with PackageKit. Sorry for the conversation with myself :) it seems that it initially installed rpmfusion-free-release-10-5.noarch , with rpmfusion-free-release-13-1.noarch available as an update (but PK refuses to update it because of the key issue). If I update to 13-1 with yum --nogpgcheck, the GPG key file now shows up. That's basically how it's supposed to work except for the nogpgcheck -- that problem should vanish once I move the latest rpmfusion-free-release from updates-testing to updates /me wanders of to do that Looks like it will take a little longer as one packages that is needed was not build for some reason. CU knurd
Re: rpmfusion and no frozen rawhide
Adam Williamson wrote on 27.04.2010 14:57: On Tue, 2010-04-27 at 14:42 +0200, Thorsten Leemhuis wrote: That's basically how it's supposed to work except for the nogpgcheck -- that problem should vanish once I move the latest rpmfusion-free-release from updates-testing to updates /me wanders of to do that I've updated the text on the web page (now I realized I just needed a Wiki account :). One other thing I noticed - the links for Rawhide seem to be 404. Noticed that in parallel :-/ Pushed a new release packages two days ago and forgot to adjust the link :-/ Cu knurd
Re: xtables-addons-1.24.1.fc13 disappeared in the repo
On 25.04.2010 15:23, Chen Lei wrote: One of my packages-xtables-addons-1.24.1.fc13.src.rpm http://download1.rpmfusion.org/free/fedora/updates/testing/12/SRPMS/xtables-addons-1.24-1.fc12.src.rpm disappeared without any notification after staying in the F13 update-testing for two weeks. /me looks puzzled Can anyone tell me why this package was removed from repo? I did some cleanups earlier today and remove kmod packages for older kernels and packages from updates-testing that were also in the updates repos. I sanity checked everything, but I guess either I or the push scripts did something stupid and removed the package for some reason (likely I) -- at least that's the only explanation that makes sense to me right now. Sorry for the trouble; please rebuild. CU knurd
Re: build errors on ppc builders
On 25.04.2010 15:13, Chen Lei wrote: On 2010-04-25 19:35:38，Dominik Rathann Mierzejewski domi...@greysector.net Wrote： I'm attaching two results from failed builds. One says it couldn't download result from the builder and the other complains about missing deps. Could the ppc builder admin check this? See https://bugzilla.rpmfusion.org/show_bug.cgi?id=1166 That's afaics the reason for the second problem in Dominik's mail (lame missing on ppc64) -- I don't know why that happens since a few days (I was bitten by that already as well). Xavier, did you change anything recently? The first problem (Job failed on arch ppc: couldn't download result files from builder) likely is related. I happened really rarely in the past already iirc, but nobody every looked into this. Dominik, bumping and rebuilding lame (and hoping everything works fine on ppc/ppc64 this time) is likely the best way to fix this and make mplayer build. CU knurd
Re: xtables-addons-1.24.1.fc13 disappeared in the repo
On 25.04.2010 15:56, Thorsten Leemhuis wrote: On 25.04.2010 15:23, Chen Lei wrote: One of my packages-xtables-addons-1.24.1.fc13.src.rpm http://download1.rpmfusion.org/free/fedora/updates/testing/12/SRPMS/xtables-addons-1.24-1.fc12.src.rpm disappeared without any notification after staying in the F13 update-testing for two weeks. /me looks puzzled Can anyone tell me why this package was removed from repo? I did some cleanups earlier today and remove kmod packages for older kernels and packages from updates-testing that were also in the updates repos. I sanity checked everything, but I guess either I or the push scripts did something stupid and removed the package for some reason (likely I) -- at least that's the only explanation that makes sense to me right now. Sorry for the trouble; please rebuild. Kicked the rebuild myself Cu knurd
Re: Why are akmod packages arch specific?
On 24.04.2010 03:22, Orcan Ogetbil wrote: Is there any particular reason? Partly that history iirc, as noarch subpackages were not yet possible in the early akmod days. Can we make them noarch? Yeah, should be possible, but might be best if tested in rawhide for at least a short while first. But here is another thought I wanted to bring up for discussion months ago: I think it might be easier to build the akmod packages from a separate source package. That way we avoid the flipping the %define buildforkernels newest macro when updating the package, which quickly is forgotten, confuses people (afaics), and makes things harder for the one that is pushing the packages and cleaning up old kmod packages in the repos. The downsides: When updating the kmod (e.g. to a newer version or when integrating a new patch) the maintainer would have to copy the foo-kmod.spec file and all the sources to a different directory and flip a bit (the name or a macro). That's a bit more work for the packager, but more natural and hence might be easier for everyone. Opinions? Cu knurd
Re: [Bug 569] please gpg-sign repomd.xml files, enable repo_gpgcheck=1 in yum .repo files
On 08.04.2010 15:07, Michael Schwendt wrote: On Sun, 4 Apr 2010 21:25:51 +0200, RPM wrote: http://bugzilla.rpmfusion.org/show_bug.cgi?id=569 --- Comment #10 from Thorsten Leemhuis 2010-04-04 21:25:50 --- (In reply to comment #9) Is this problem fixed ? I would not call it a problem, more a RFE -- for something that even Fedora sill doesn't do iirc but whatever: seems this is one of the dozens of things in RPM Fusion that really would be nice to fix or improved, without anybody working on it :-(( (and most of the other things that need to get improved are way more important IMHO) RFEs like this are in need of _somebody_ to make decisions. I would agree for most RFE's. But not for this specific RFE: There is (afaics) no real downside for users. So there is not much to discuss IMHO, it just needs somebody to do it and work out the details -- and start a privte or public discussion in case problems emerge where a discussion and a decision is needed. But discussing that without knowing that anybody will work further on it seems like a lot of wasted time for me. [...] A fundamental problem with RPMFusion is that at the management level there is no work-horse to just do it, i.e. to decide on something and work with contributors on feasible solutions. I partly did that in the past, but as I said multiple times: I don't want to anymore for now and I'm willing to support individuals or (preferred better) a group of people that want to take of steering and governing RPM Fusion. Where something sucks, it needs somebody to say we want to improve in that area and to put something onto an agenda (or call it wishlist). Maybe yes, but in RPM Fusion that IMHO didn't help much until now, as we are (afaics) to few people. Take the repoclosure scripts for example -- it now years ago was definitely planed to run them after each push and you even did some groudwork to make it easy for our sysadmins to integrate (thx again for that), but they never got installed on our servers (and there were many situations where the lack of automated repoclosure scripts was discussed on this list, so it was never really forgotten). Cu knurd
Re: RPM Fusion (Fedora - free) Package Build Report 2010-02-26
rpmfusion-pkgs-rep...@rpmfusion.org wrote on 26.02.2010 13:11: Packages built and released for RPM Fusion (Fedora - free) 12: 1 gstreamer-plugins-bad-0.10.17-4.fc12 That is not the case actually -- I accidentally moved it to updates-proper as I thought the new gst-plugin-packages on the Fedora side got pushed, but was wrong and moved them back before the push was done. CU knurd
Re: rpmfusion and no frozen rawhide
On 17.02.2010 09:36, Hans de Goede wrote: So how are we going to handle the new no frozen rawhide ? That's a very interesting question -- especially as our development branch still builds against rawhide which sine a few hours is heading towards F-14. IOW: something should happen soon... I see 2 options: [...] 2) Do early branching, just like Fedora does. We could make it a bit easier on ourselves by immediately putting the new F-## repo next to the already released repo's instead of putting it under development like Fedora does. Just my 2 cent: In an ideal world we IMHO wouldn't do anything different from Fedora to avoid any confusion -- even if it's feels like we are doing something that looks better or easier... Cu knurd
Heavily reducing my involvement in RPM Fusion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I have not been very active in RPM Fusion (or Fedora) lately. Partly that's because my day job and private life consume more time than two or three years ago (and it'll get worse over the coming months, as as I have to move to a new apartment in March/April). Another reason: Working on RPM Fusion stuff isn't as much fun for me as it used to be -- it instead way to often feels like a (heavy) burden. That has multiple reasons -- some (not all!) of them lie in RPM Fusion and its packages, but I don't have enought energy to work on fixing those issues (sorry!). I would have preferred to slowly and mostly unnoticeable reduce my involvement, but I guess that wouldn't be ideal for the project as a whole, as I have some crucial positions and people counting/relying on me and the work I do/did in the past (which in the past few months I didn't do as good as I would have liked; I apologize for that). That's why I try to make it really obvious with this mail that I'm heavily reducing my involvement from now on. Think of it a bit like Thorsten will be leaving us by start of the summer (to be clear: summer in the northern hemisphere of 2010 ;-) ) and he only does those things from now on that he really has to do to keep RPM Fusion running, as there is no replacement (yet). No, I don't think I'll leave completely, but it might be best for everyone if it feels a bit like that, to make sure people that take over my work can be found early enough. That means that I'll from now on will focus on pushing packages, do the kmod rebuilds for new kernels and keep the packages I own working, but with the least amount of work possible (e.g.: updates, but no big improvements to things like the kmod infra) for now. In other words, I won't do the following things anymore if there isn't a strong reason for me to do them - - actively watch bugzilla and mailing lists for bigger problems in the repos that bug lot's of people - - CVS requests - - buildsys issues - - try to make sure every mail on the RPM Fusion lists get's answered sooner or later (have been doing that in the early day, but failed to do that for some time now) - - help to make the project grow -- solve problem packagers have, bring people together, help getting stalled reviews running again and things like that - - a lot of other things my mind doesn't come up with right now Read the above I won't do the following things anymore if there isn't a strong reason for me to do them as in: I'll nevertheless do some of the work (like kicking the builders or preparing the repos for F13) if no one else is able to do when needed -- but I can't do that forever, so the RPM Fusion contributors really should try to find people that can take care of things, as I sooner or later might completely stop doing that work to finally get it rid of my back ;-) But I'll of course stick around and will help with answering questions when needed, as I still want RPM Fusion to live on and grow. In fact I sooner or later might get involved more deeply again or do new things in Fedora or RPM Fusion if I feel like it (in fact there is a idea that I'd really like to realize sooner or later in a repo which could live under the hood of RPM Fusion if that's wanted by the project leaders then); time will tell. That's all for now! I hope I didn't forget anything important... Cu knurd P.S.: There are still a few mail on this list I would like to answer; I'll hope to find time for that over the next few days -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktokrwACgkQUjQh93TopkG5GACfTe7JtFpSpIwAxUuuhP/uhru1 dOoAn1iv8uaoJi4b4YgA2dLmrNhubJtS =d3Fy -END PGP SIGNATURE-
Re: Push needed for audacious-freeworld package
Michael Schwendt wrote on 01.02.2010 09:46: On Mon, 01 Feb 2010 07:23:38 +0100, Thorsten wrote: Michael Schwendt wrote on 31.01.2010 23:45: Somebody please push the audacious-freeworld test update for F-12 free into stable. Shall I push it immediately ot try to sync it with the next Fedora push? Dunno how feasible that is considering mirror sync times and Bodhi bugs. Making the -freeworld pkg available before Audacious 2.2 would be safer due to strict dependencies. It's possible to see an ongoing push something like 4 to 10 hours before the new stuff hits the mirrors by watching koji tags closely. As Fedora also has mirror sync times I'd prefer to push the new audacious plugins package later today or when I see that a push on the Fedora side was started (if that's fine for you). Or IOW: Will the 2.2-add-on-package work with the old audacious? It's the opposite: The old add-ons are incompatible with the new Audacious. Yeah, that was obvious ;-) However there is no dependency to reflect that. They would be disabled at run-time. The new add-ons require the new Audacious plugins version. Hence they can only be installed as soon as the new Audacious becomes available, too. Ahh, okay, so only broken deps on our side then for a while. Not nice, but acceptable afaict. Cu knurd
Re: Push needed for audacious-freeworld package
On 01.02.2010 09:54, Thorsten Leemhuis wrote: Michael Schwendt wrote on 01.02.2010 09:46: On Mon, 01 Feb 2010 07:23:38 +0100, Thorsten wrote: Michael Schwendt wrote on 31.01.2010 23:45: Somebody please push the audacious-freeworld test update for F-12 free into stable. Shall I push it immediately ot try to sync it with the next Fedora push? Dunno how feasible that is considering mirror sync times and Bodhi bugs. Making the -freeworld pkg available before Audacious 2.2 would be safer due to strict dependencies. It's possible to see an ongoing push something like 4 to 10 hours before the new stuff hits the mirrors by watching koji tags closely. As Fedora also has mirror sync times I'd prefer to push the new audacious plugins package later today or when I see that a push on the Fedora side was started (if that's fine for you). Push on the Fedora side in progress; plugins-freeworld package is moved to our stable updates right now. CU knurd
Re: Push needed for audacious-freeworld package
Michael Schwendt wrote on 31.01.2010 23:45: Somebody please push the audacious-freeworld test update for F-12 free into stable. Shall I push it immediately ot try to sync it with the next Fedora push? Or IOW: Will the 2.2-add-on-package work with the old audacious? CU knurd
Any remaining work for F-10?
Hi! Is there any remaining work for our F-10 repos or can we officially call them EOL in sync with Fedora (which iirc means tomorrow)? Cu knurd
Re: RPM Fusion for EL (Was: Re: Supporting Moblin?)
On 01.12.2009 22:44, Jack Neely wrote: On Wed, Nov 25, 2009 at 09:30:28AM +0100, Thorsten Leemhuis wrote: Michel Alexandre Salim wrote on 25.11.2009 02:33: We've so far provided add-on packages for Fedora and RHEL; Nope, the latter was never really started and interest in it seems quite low -- I likely sooner or later will suggest we drop it completely if nobody steps up and feels responsible for it/takes care of it: http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2009-February/004058.html [...] I'll state that I'm interested in EL support from RPMFusion. I'm planning on having some time toward this spring to work about getting some of the commonly used kernel modules my shop depends on for RHEL 6 well maintained in RPMFusion. Sounds lame, but those that want to do it simply should start doing it, otherwise RPM Fusion for EL afaics will fail before it even started for real :-/ IOW: There is nobody that will tell you Yes, you have the job; It's more just do it IOW afain ;-) Just start doing some work to make RPM Fusion for EL solid. Some ideas to start working: - check if all the deps in the current EL repo are satisfied and poke package maintainers to fix it if not - check if everything is working, if not, poke maintainers - check if all the important packages people often want are in the EL repo - owners.epel.list in our CVS is afaics not sully up2date - work towards officially announcing RPM Fusion support for EL I's not my decision alone, but I'd be willing to hand someone the signing keys for the EL repo, in case that someone - works on above list for at least a few weeks and thus shows he committed to the job - seems trust-able (e.g. ideally someone that is known in Fedora-land already and not something new coming out of the blue) - got access to the push server (which is something the Admins will have to work out) Cu knurd
Re: gnome-do subpackages
On 10.12.2009 18:41, Juan Rodriguez wrote: On Wed, Nov 18, 2009 at 12:05 PM, Juan Rodriguez nus...@fedoraproject.org mailto:nus...@fedoraproject.org wrote: With that, we can continue shipping gnome-do 0.8.2 and its plugins in Fedora, and once 'Docky' is ready, we can ship that, and docklets, with full functionality, in RPMFusion instead, and Docky will be gone from gnome-do anyways. gnome-do 0.8.3.1 has been released, and after talking to the developers, I'd rather have that version on RPMFusion (With Zoom functionality), than leave it on Fedora sans-zoom. How can I start the package migration process? File a CVS request in bugzilla. Details: http://rpmfusion.org/Contributors CU knurd
Re: Cleanup on builders needed, there is not enough free space to build sdlmame
Julian Sikorski wrote on 01.12.2009 10:52: all 3 sdlmame jobs failed today. Please free up some space on the builders. Done, jobs restarted. /me wonders if it might be wise to make tmpwatch automatically remove old stuff from /var/lib/mock/ if it doesn't do that already Cu knurd
Re: 403 - Forbidden on rpmfusion-nonfree-updates-testing
SmootherFrOgZ wrote on 29.11.2009 20:53: On Sun, Nov 29, 2009 at 9:59 AM, Thorsten Leemhuis fed...@leemhuis.info wrote: On 29.11.2009 08:31, Orcan Ogetbil wrote: On Sat, Nov 28, 2009 at 6:17 PM, Orcan Ogetbil wrote: Something wrong in bombadil builder. It looks like it's fixed. Thanks to whoever did that. That was me. And sorry for the trouble. The first problem you had (repodata directories on the public reops have wrong permission) is a side effect of fixing the second problem you had (repodata for the needsign not regenerated properly after the push script removed packages, as the permission of the directories make createrepo fail). I hope Xavier looks into that soon. yep, did some changes I gonna need you to do some tests and report them to me. Did a push and the repodata directories that were generated once again got wrong permissions: ls -ld [...]free/fedora/updates/testing/11/ppc64/repo* drwxrwx--- 2 thl rpmfusion-signers 4096 Nov 30 09:03 [...]/free/fedora/updates/testing/11/ppc64/repodata CU knurd
Re: 403 - Forbidden on rpmfusion-nonfree-updates-testing
On 29.11.2009 08:31, Orcan Ogetbil wrote: On Sat, Nov 28, 2009 at 6:17 PM, Orcan Ogetbil wrote: Something wrong in bombadil builder. It looks like it's fixed. Thanks to whoever did that. That was me. And sorry for the trouble. The first problem you had (repodata directories on the public reops have wrong permission) is a side effect of fixing the second problem you had (repodata for the needsign not regenerated properly after the push script removed packages, as the permission of the directories make createrepo fail). I hope Xavier looks into that soon. CU knurd
Re: 403 - Forbidden on rpmfusion-nonfree-updates-testing
Nicolas Chauvet wrote on 26.11.2009 18:12: http://download1.rpmfusion.org/nonfree/fedora/updates/testing/11/x86_64/repodata/repomd.xml cannot be acceded so mirrors arent't expected to rsync. Xavier did some changes in the past 24 hours, guess that's a unwanted side effect :-/ I worked around that my adjusting the perms with chmod manually for now. Xavier, can you make sure it doesn't happen again with the next push? tia! CU knurd
RPM Fusion for EL (Was: Re: Supporting Moblin?)
Hi! Michel Alexandre Salim wrote on 25.11.2009 02:33: We've so far provided add-on packages for Fedora and RHEL; Nope, the latter was never really started and interest in it seems quite low -- I likely sooner or later will suggest we drop it completely if nobody steps up and feels responsible for it/takes care of it: http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2009-February/004058.html [...] Cu knurd
Fwd: No Frozen Rawhide Meeting Summary
Forwarding this here, just to make sure everybody sees it, as I guess we have to simply follow Fedoras lead here and lay our repos out in a similar fashion to make sure users of rawhide and current release +1 get everything they need and test our stuff. CU knurd Original-Nachricht Betreff: No Frozen Rawhide Meeting Summary Datum: Mon, 23 Nov 2009 11:37:27 -0800 Von: Jesse Keating jkeat...@redhat.com Antwort an: Development discussions related to Fedora fedora-devel-l...@redhat.com Organisation: Red Hat An: Development discussions related to Fedora fedora-devel-l...@redhat.com Last week we had a Fedora Talk meeting regarding the No Frozen Rawhide proposal. This meeting was to quickly get everybody back up to speed on the proposal, walk through a typical release cycle, and identify the parts of the proposal that still need work. We then outlined what the blocking items were, and not-so-blocking with available workarounds, and who would be responsible for getting the blockers done and the schedule for completion. There was a gobby session open at the time too, and notes were taken from the meeting. They can be found at the bottom of this message. The high level plan is as follows: - Continue to produce rawhide as a repo of packages without install images. - At feature freeze, branch CVS for F-13 - devel/ now builds for F-14, reflect that in fedora-release and koji - F-13 builds are published to pub/fedora/linux/releases/13/Everything/ nightly - Potential F-13 builds are published to pub/fedora/linux/updates/testing/13/ either nightly or as part of standard updates pushes. - Bodhi will be used for managing builds from F-13. Push to testing goes to the updates-testing location. Push to stable goes to the Everything/ path. - Install images created in the Everything/ path. - Packages in the critical path will require positive karma from releng or qa before allowed to go stable. Packages outside the critical path will be managed just as updates are now. - At F13 Release Candidate stage, pushes to stable will go to pub/fedora/linux/updates/13/ instead of the Everything/ path. Release blocking fixes will be pulled into Everything/ There are lots of other details to the above, but that's a good overview. There are some major obstacles to getting this done, the two biggest being bodhi and the compose infrastructure. Bodhi is currently being rewritten, partly to enable us to add the functionality we need. I have an action item to sync up with Luke Macken to make sure he is aware of our needs and will be able to implement them in time for F13 Feature Freeze. If not, we have a fallback to using trac for tag requests, but very non-optimal. The compose infrastructure needs some improvement to be able to handle making multiple trees each day, as well as additional updates repos. Bill Nottingham is taking the lead on this work and will be investigating various ways to speed up our processes. This is the one true blocker to this effort, if we simply do not have the resources to compose a never ending rawhide plus a pending release, we will have to postpone these changes until such resources are obtained. We will continue to talk about no frozen rawhide and get updates from the various tasks being worked on in our weekly release engineering meeting (Mondays at 1800 UTC), and I suspect we'll be talking about it quite a lot at FUDCon in Toronto. Please feel free to contact me on IRC, or post to fedora-devel-list if you have any questions regarding this proposal and how Fedora development will operate in the future. Below you'll find the gobby notes from our meeting: Attendees: John Poelstra, Bill Nottingham, Jesse Keating, Dennis Gilmore, James Laska, Warren Togami, Steven M. Parrish, add yourself https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal (aka NFR :) Right now: - rawhide is pulling from F-13 - rawhide does not have images At some point: - rawhide will pull from F-14 - we will branch everything in CVS, and start a second F-13 tree - we create the F-13 version in bugzilla (and any other associated things in our normal process) - we do 'something' in fedora-release and mirrormanager to put people on the right repos -- where does this tree go. releases/13/Everything? +1+1 -- testing updates to go updates/testing/13/ --- make sure this path is OK with mirrors Possible Alternatives - at feature freeze? +1+1+1+1 - at beta freeze? How it works for developers, after branch: - tag - build - 'make update' Tool changes/scope: * koji/release engineering ** need autosigning *** Assignee: Jesse * releng scripts ** need to be able to build a second nightly tree *** Assignee: Jesse, Bill * mash ** needs to be able to build trees faster. HOW? *** Split packages into subdirs (Seth's idea) *** Use multiple compose boxes *** (kill multilib?) *** (kill deltas?) (updates only?) *** Assignee: Bill, Jesse * Bodhi ** need to have 'pre-release' updates that go into an updates-testing,
Re: libGLcore.so.1: cannot open shared object file: No such file or directory
Neal Becker wrote on 22.11.2009 23:30: Got nvidia xorg-x11-drv-nvidia-190.42-2.fc12.x86_64 But I see this: (II) Loading /usr/lib64/xorg/modules/extensions/nvidia/libglx.so dlopen: libGLcore.so.1: cannot open shared object file: No such file or directory Ideas? Just a friendly reminder: You sent a lot of problems with the nvidia drivers to this list in the past. Most of them in *my* humble option are more off topic here and on topic on http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-users (And yes, the driver packages IMHO have problems that are fine to get discussed on this list, but this doesn't seem to be one of them IMHO) CU knurd
CVS branched, builders ready for F12 (Was: Re: Repos for F12 should be ready)
On 15.11.2009 18:58, Thorsten Leemhuis wrote: The buildsys and cvs are not yet fully adjusted/branched for F12. They are now. Let me know if there are any problems. And don#t forget to update your common checkout ;-) Cu knurd
Re: gnome-do subpackages
Hi! Juan Rodriguez wrote on 18.11.2009 16:32: My name is Juan Rodriguez, and I currently maintain a pair of packages for Fedora 10, 11 and 12. One of those packages I maintain is gnome-do, (and gnome-do-plugins), with gnome-do-docklets along the way. However, it has come to my attention that gnome-do's docky interface violates US Patent 7434177 [1], which in turn, crippled gnome-do by removing docky from the Fedora's package. I'd like to request for it to join the RPMFusion repositories instead. As mentioned on IRC: We iirc allow packages that got removed from Fedora to enter RPM Fusion without additional review. If my memory serves me correct (e.g. if nobody yells over the next 2 days) then file a CVS reqeuest for gnome-do and gnome-do-plugins and apply for membership in FAS. You'll find details how to do that on http://rpmfusion.org/Contributors HTH Cu knurd
Re: Should preupgrade with rpmfusion work?
Neal Becker wrote on 16.11.2009 12:32: When f12 release is official, should preupgrade work, including rpmfusion (assuming I have enough space in /boot)? I already tried it, and it failed due to rpmfusion dependencies. I read that preupgrade should do everything right these days, but I never tried myself. CU knurd
Re: Packages in F12 repositories signed with the F11 key
Mary Ellen Foster wrote on 16.11.2009 14:59: Hi! I just installed F12 (from the RC disk) on a new computer, and discovered that there seem to be packages in the F12 rpmfusion repositories that are signed with the F11 signing key. The specific one that I noticed was livna-config-display, which refused to install until I downloaded and rpm --imported the GPG key for F11. Is this a known issue? This actually should be a fixed issue as of a few hours ago. Guess you hit a not-up2date mirror. Sorry for that, was my fault. /me still wonders why none of the fresh rawhide users complained over the past few months There do seem to be a lot of packages with fc11 in their name; the following command counted 207 packages... yum --disablerepo=* --enablerepo=rpmfusion-* list available | grep fc11 | grep -v debuginfo | wc -l This is a FAQ not specific to rpmfusion that google can answer. yum --disablerepo=* --enablerepo=fedora* list available | grep fc11 | grep -v debuginfo | wc -l 147 In short: It's not a problem, just ignore. The full truth is that RPM Fusion didn't to a mass-rebuild this release cycle and Fedora did, that's why the number is quite for RPM Fusion and quite low for Fedora. CU knurd
Re: Repos for F12 should be ready
Kevin Kofler wrote on 16.11.2009 18:43: Thorsten Leemhuis wrote: Conrad Meyer wrote on 15.11.2009 21:58: Can you post about what steps were involved in this process? In Detail: No, as that would take multiple hours. But the rough and mostly (not fully) up2date steps can be found on http://rpmfusion.org/Infrastructure/PrepareRelease Well, I know you're busy with doing the actual work, but I think lack of documentation is one of the reasons why RPM Fusion doesn't have any new admins outside of the existing inner circle volunteering. I fully agree. But talk to Xavier about that, I'm considering myself only the rel-eng guy that highly unwillingly did some infra work here to make sure RPM Fusion keeps running properly. Also note that even I don't know how some things work in the infra area. That's for example the reason why CVS isn't branched yet. IOW: I want documentation and guidance from Xavier as well. From the rel-eng standpoint there is not much documentation needed, as the main parts are already on above page, obvious (but yes, that page can be improved a lot) or documented on the Fedora side. The latter IMHO is what we should aim for in general and only document things where we differ, as that makes everybody's life easier. There's no way for a new volunteer to start helping out if they don't know what they're supposed to do. :-( Fully agreed. And I'm willing to help explaining things to people that want to help when needed, but first Xavier has to let people in -- which he afaics is preparing for. CU knurd
Repos for F12 should be ready
Hi! I created the final repos for F12, the release rpms for them and did the first pushes. Everything seems to be sane at this point -- if not let me know soon, as now it's still easy to fix things in the final repos. The buildsys and cvs are not yet fully adjusted/branched for F12. I did a lot of preparation work for the builders(¹), but there iirc are some things Xavier does in CVS to prepare for a new release that only he knows about. CU knurd (¹) I still don't want to do that sort of work, but I guess preparing it myself was the fasted way to make sure things mostly went smooth for everybody
Re: Any remaining work for F12 repos?
On 14.11.2009 22:08, Nicolas Chauvet wrote: 2009/11/10 Thorsten Leemhuis fed...@leemhuis.info: Our rawhide trees seem to be in a mostly sane state now. Here is a list of steps I'm aware of before the Everything repos for F12 can be created: [...] Anything else? If yes, then please speed up, as I'd would like to create the Everything repos on Friday -- updating them afterwards is a lot of manual work, hence I'd like to avoid that. OK for me once we have the last Cg and mock-rpmfusion* in GA repository. Just for completeness: I think it's totally ^w very bad to build packages on the very last minute for the F12 repos without strict need, as they now will be in there for the whole lifetime of F12 now, even if they contain serious bugs (¹). Nevertheless I pushed them, as that obviously was what you wanted. But But I'd vote that we for the next release have a real repo freeze for a week or two, where only those things get changed in the last minute where the benefit outweighs the risk. Just my 2 cent. Cu knurd (¹) that's not completely trues, as it's possible to get them out there, just a lot of manual work that I would have to do
Re: Repos for F12 should be ready
Conrad Meyer wrote on 15.11.2009 21:58: On Sunday 15 November 2009 09:58:34 am Thorsten Leemhuis wrote: I created the final repos for F12, the release rpms for them and did the first pushes. Everything seems to be sane at this point -- if not let me know soon, as now it's still easy to fix things in the final repos. The buildsys and cvs are not yet fully adjusted/branched for F12. I did a lot of preparation work for the builders(¹), but there iirc are some things Xavier does in CVS to prepare for a new release that only he knows about. [...] (¹) I still don't want to do that sort of work, but I guess preparing it myself was the fasted way to make sure things mostly went smooth for everybody Can you post about what steps were involved in this process? In Detail: No, as that would take multiple hours. But the rough and mostly (not fully) up2date steps can be found on http://rpmfusion.org/Infrastructure/PrepareRelease CU knurd
Any remaining work for F12 repos?
Hi! Our rawhide trees seem to be in a mostly sane state now. Here is a list of steps I'm aware of before the Everything repos for F12 can be created: - move the nvidia-driver to the nonfree-updates-testing repositories, as requested by kwizart (#928) - push the new em8300-kmod to the updates repos, once they exist; move vdr-dxr3 there, as it depends on em8300-kmod (#920) - push a older picard-freeworld, if one shows up in time (#932) Anything else? If yes, then please speed up, as I'd would like to create the Everything repos on Friday -- updating them afterwards is a lot of manual work, hence I'd like to avoid that. CU knurd
Re: rsync problems with download1.rpmfusion.org
Adrian Reber wrote on 02.11.2009 13:02: I am seeing intermittent errors when connecting to download1.rpmfusion.org. Sometimes it works but most of the time I get: rsync: read error: Connection reset by peer (104) rsync error: error in rsync protocol data stream (code 12) at io.c(759) [receiver=3.0.6] Pix (CCed) is afaik the only one that can fix this. He normally is reachable via IRC, but until now hasn't been online today :-/ This is means that mirrormanager probably does not give out a 100% correct mirrorlist, because it does not know what the newest packages are. I also cannot update my own mirror. If somebody can please check why this is happening... That would be great. Would it be easily possible to reconfigure mm to make it return only download1.rpmfusion.org until this gets fixed? CU knurd
Re: [Bug 908] New: Review request: Mupen64Plus - Emulates the Nintendo 64 game console
Andrea Musuruane wrote on 02.11.2009 15:06: On Sat, Oct 31, 2009 at 11:50 AM, RPM Fusion Bugzilla nore...@rpmfusion.org wrote: http://bugzilla.rpmfusion.org/show_bug.cgi?id=908 Summary: Review request: Mupen64Plus - Emulates the Nintendo 64 game console Product: Package Reviews Version: Current Platform: All OS/Version: GNU/Linux Status: NEW Severity: normal Priority: P5 Component: Review Request AssignedTo: rpmfusion-package-rev...@rpmfusion.org ReportedBy: packa...@amiga-hardware.com CC: rpmfusion-package-rev...@rpmfusion.org Blocks: 2 Estimated Hours: 0.0 I cannot no longer access this bug. Why? Regards, Should work now -- seems Bugzilla now and then checks the Only users in all of the selected groups can view this bug checkbox for some strange reason. Cu knurd
Re: How to move on with infrastructure?
On 01.11.2009 09:06, Kevin Kofler wrote: Thorsten Leemhuis wrote: - multiple people offered to help in the past (²), but not even one of those people found its way into the project/the infrastructure team: Why? It can't continue like that, as that is a route to fail... Well, because… I could give you access in some areas, but I also only partly know how things work. And for now I would prefer not to hand out access to not mix things up even more and to not get into Xaviers way. ;-) If you ask people for help, you also need to give them the required access they'll need to help you. I'm not the infrastructure lead for RPM Fusion, Xavier is. He should handle and coordinate that, and that's what I hoped to archive when I started this discussion. Or, to say it differently: Consider in Fedora that someone from rel-eng would not really be happy with the work of the current Fedora infra team. Assume further that this rel-eng person still has admin permissions everywhere in FAS, as he did some infra work in the past, but stopped a while ago. Should this rel-eng person thus use this power and simply add people to the infra group in FAS and without bothering to ask the infra lead? I'd say the answer is a definite no, as long as the infra lead is still around and does his job good enough (IOW: as long as the benefits outweigh the risks and disadvantages). CU knurd
Re: RPM Fusion (Fedora - nonfree) Package Build Report 2009-10-25
On 31.10.2009 14:18, Andrea Musuruane wrote: On Sun, Oct 25, 2009 at 1:35 PM, rpmfusion-pkgs-rep...@rpmfusion.org wrote: Packages built and released for RPM Fusion (Fedora - nonfree) testing/11: 1 libcapsimage-2.0.0-10.fc11 Changes in RPM Fusion (Fedora - nonfree) testing/11: libcapsimage-2.0.0-10.fc11 -- * Sun Mar 29 2009 Thorsten Leemhuis fedora [AT] leemhuis [DOT] info - 2.0.0-10 - rebuild for new F11 features Can someone please move these to stable? I need it to build e-uae. updates-testing is enabled in the configuration of all our builders, so there is no need to move it afaics. But note, I'll likely do a stable move soon anyway, so it might get moved there depending on how old the package is. CU knurd
Re: kmod-nvidia in rawhide?
On 22.10.2009 00:49, Nicolas Chauvet wrote: 2009/10/21 Thorsten Leemhuis fed...@leemhuis.info: On 21.10.2009 21:20, Nicolas Chauvet wrote: 2009/10/21 Jarod Wilson ja...@wilsonet.com: On Oct 21, 2009, at 3:04 PM, Nicolas Chauvet wrote: 2009/10/21 Dominik 'Rathann' Mierzejewski domi...@greysector.net: Could someone (Nicolas?) push nvidia's 190.40 drivers to rawhide? I've built new RPMs locally based on latest from f11-updates and they've been working fine for the last few days (and they work with F12's Xserver ABI changes). Right, but the new packaging scheme is on the way. New packaging scheme? /me missed something... Was delayed because the work on multimedia libs update. May I not be the only one to work on rawhide ? Please! I'll take care of 190.40 drivers for rawhide right now. No that's not What I meant. mplayer and avidemux along with a mass rebuild is needed. Furthermore selinux still isn't compatible with the nvidia drivers yet. What You 've just subscribed is the review request pending for the new review. Just my 2 cent: I'd much prefer to get the driver in asap, especially if any reviews for other packages are needed before that can happen. We are running out of time for F12 and users are annoyed that we don't ship the drivers. Or, IOW: Is there any downside in doing what Dominik and Jarod suggested and just updated the drivers? If your new scheme gets ready in time we can switch over easily -- we need to provide and test the upgrade path anyway... It just ??? (nvidia-xsetting and nvidia-xconfig splitted fom the driver at least) Weren't those reviewed earlier already? At least there is no cvs created for them. Hmmm. Seems my mind fooled me. Guess I mixed it up with nvidia-settings, which was in Livna for a short time and then removed again shortly before or after the the merge iirc. CU knurd
Re: Someone kick psb-kmod to stable updates?
Hi! Adam Williamson wrote on 22.10.2009 19:01: Can someone please kick psb-kmod to F11 stable updates? The other Poulsbo packages have shown up there, but not the kmod. Sorry, my fault, forgot to move the kmod for some strange reason when I moved the other packages. Push in progress now. Had to do it manually, hence it'll likely not show up in the report. CU knurd
