Hosting the live cd
by Rahul Sundaram
Hi,
I would like to start hosting omega as part of rpmfusion
infrastructure. A subdomain like omega.rpmfusion.org would be a good
space. Thoughts? Anyone testing the rawhide snapshots?
Rahul
15 years, 6 months
RPM Fusion (Fedora - free) Package Build Report 2008-10-12
by rpmfusion-pkgs-report＠rpmfusion.org
============================================================================
Packages built and released for RPM Fusion (Fedora - free) testing/9: 1
vagalume-0.7-1.fc9
============================================================================
Packages built and released for RPM Fusion (Fedora - free) testing/8: 1
vagalume-0.7-1.fc8
============================================================================
Packages built and released for RPM Fusion (Fedora - free) development: 1
vagalume-0.7-1.fc10
============================================================================
Changes in RPM Fusion (Fedora - free) testing/9:
vagalume-0.7-1.fc9
------------------
* Tue Sep 02 2008 Michel Salim <michel.sylvan(a)gmail.com> - 0.7-1
- Update to 0.7
* Mon Aug 04 2008 Thorsten Leemhuis <fedora [AT] leemhuis [DOT] info> - 0.6-4
- rebuild
============================================================================
Changes in RPM Fusion (Fedora - free) testing/8:
vagalume-0.7-1.fc8
------------------
* Tue Sep 02 2008 Michel Salim <michel.sylvan(a)gmail.com> - 0.7-1
- Update to 0.7
* Mon Aug 04 2008 Thorsten Leemhuis <fedora [AT] leemhuis [DOT] info> - 0.6-4
- rebuild
============================================================================
Changes in RPM Fusion (Fedora - free) development:
vagalume-0.7-1.fc10
-------------------
* Tue Sep 02 2008 Michel Salim <michel.sylvan(a)gmail.com> - 0.7-1
- Update to 0.7
* Mon Aug 04 2008 Thorsten Leemhuis <fedora [AT] leemhuis [DOT] info> - 0.6-4
- rebuild
15 years, 6 months
cvs.rpmfusion.org not working for me (ssh keys?)
by Rex Dieter
I've been fighting trying to get access to cvs.rpmfusion.org the past 2
days, without luck. Maybe I'm doing something fundamentally wrong.
I import my public keys into fas, then follow instructions on
http://rpmfusion.org/Contributors#head-014c352d2815a61a3a0583acc3819fc50b...
and alter my ~/.ssh/config to use the proper private key. I tried both
using the same key I use for fedora, as well as generate a separate
rpmfusion-only key. Neither seems to work. I only get:
$ echo $CVSROOT
:ext:rdieter@cvs.rpmfusion.org:/cvs
$ echo $CVS_RSH
ssh
$ cvs co free
Permission denied (publickey,gssapi-with-mic).
cvs [checkout aborted]: end of file from server (consult above messages
if any)
??
-- Rex
15 years, 6 months
nVidia drivers: series introduction, upgrade, deletion.
by Nicolas Chauvet
Hi !
With this message I would particularly focus on one problem with the
nVidia driver "maintainability" via the rpmfusion_nonfree repository.
The new stable nVidia driver 177.80 has dropped support for Geforce
serie 5 (NV3X) cards. This means that if we update xorg-x11-drv-nvidia
to the 177 serie in our stable release, users will have their X sessions
to collapse.
Hence, we need to set up a simple policy about how to have the nVidia
driver updated when support range for cards has changed. The update will
have to append quietly if done within a fedora stable release (F-8/F-9
currently). But may(1) need a "documentation regression" (2) If users
want to switch to the lastest or want to upgrade (From F-8/F-9 to F-10)
having missed the xorg-x11-drv-nvidia to xorg-x11-drv-nvidia-173xx
transition.
So, to sum-up and try to keep this simple:
We need to introduce a new legacy serie as the 173xx version, splited
from the "main" xorg-x11-drv-nvidia.
- In F-8/F-9 (Fedora stable - despite I wonder if we will introduce 177
in F-8).
We will rename xorg-x11-drv-nvidia to xorg-x11-drv-nvidia-173xx (along
with the related nvidia-kmod to nvidia-173xx-kmod). That way, users with
NV30 will not experience breakage).
Then we will introduce the 177 driver as xorg-x11-drv-nvidia-lastest
- In Rawhide (F-10) we will just update xorg-x11-drv-nvidia to 177 and
Obsoletes the 177 serie (xorg-x11-drv-nvidia-lastest) introduced in F-8/F-9.
IMO, I would prefer to introduce xorg-x11-drv-nvidia-lastest in Fedora
stable either or not it is a beta version. But I would like to reserve
this when the support range for nVidia hardware has changed.
Note on the nVidia beta drivers and repositories behaviors.
Previously on livna.org, we used to have a separate branch for packages
with F-? to F-?.testing from our svn, ending in the livna-testing
repository. Having such beta drivers in livna-testing doesn't prevent
the stable driver to be updated (or kmod to be rebuilt), and leads to
separated repositories.
As opposite, "fedora like" repositories behavior is to push update from
updates-testing and then, once QA, to the updates(stable).repo.
This behavior is particularly needed for the nVidia driver update.
But having a separate repository for blending edge beta version is missing.
One argument not to split "-beta" as another package is that there are
already lot of series to maintain (nvidia, 173xx, 96xx, 71xx). And the
reason why we split serie is driver range support (3), not driver status
(stable/beta).
So as such, beta can also be a legacy serie. (even if that's not
probable). And it will be easier to test a beta activating another repo
than to uninstall/reinstall a package.(4)
So any questions/wonders/advices ?
(This scheme will be introduced in rpmfusion only IMO)
Nicolas (kwizart)
(1) Depend if the parallel mode if validated.
(still in WIP, but won't be activated that soon).
(2) I mean, users will have to RTFM.
(3) We can also have a nvidia-custom specs for having a particular
version packaged, but that will not be provided within the repository.
(4) Keep in mind that driver update often needs reboot (or done in
init3) to prevent version mismatch and other side effects.
15 years, 6 months
Do we need rpmfusion-unstable repositories ?
by Nicolas Chauvet
Just with my previous message. I've suggested the need of having the
nvidia beta driver provided from a separate repository.
Actually there are others cases where it would be needed:
-vlc is now at 0.9.x but still has very hard regression (VLM, vlvc,
interaction with dependents software) from 0.8.6x, which last is
officially unsupported (despite the unreleased 0.8.7 version is here to
collect patches).
- ieee1394 stack is still needed for some driver like
http://www.ffado.org/ (it may also need compat-libraw1394 unless the
dual stack mode works).
- Experimental packages (that do not fit Fedora guideline yet) could
benefit to be widely distributed. (I'm think of freevo from my personal
repository right now, which isn't ready for review yet).
- Might be other needs...
For theses needs, the current design of the rpmfusion repositories
doesn't provide a solution yet.
So this repository could be defined as such:
- Reserved for developers, experienced users, adviced users.
- What unstable means here isn't only beta software, but also
* software that was not qualified as stable on a given "Fedora ABI
freeze", thus can lead to packages interaction problem. (vlc updated to
0.9.x / libraries such as ffmpeg with ABI/API bump for testing before to
update in rpmfusion-stable).
* Technology choices not keepted (ieee1394/juju) but still having
regression for some special use (ffado)
- Repository shouldn't be activated by default in any case (no kmod for
all kernels will be garanted, so better to use akmod ).
- Users shouldn't use "wide update" but only targeted update.
(like yum update --enablerepo=rpmfusion-unstable xorg-x11-drv-nvidia)
- Package replacement could be allowed from either Fedora/RPMFusion but
should be prevented for "long term"/or common use, specially when an
alternative solution is possible.
- Repository requirement will be unsorted but may needs dependencies
with fedora only, rpmfusion_free and rpmfusion_nonfree.
(there will not be an unstable repository for each possibility of
interaction).
- Do you see others case where it would be needed?
- It it doable to implement cleanly on the buildsys?
(I May try to help at the admin level if needed).
IMO it doesn't matter to have it ready to open rpmfusion (if even we
are ready). So there is no timeline for this feature. But it could be at
least discussed.
Nicolas (kwizart)
15 years, 6 months
Re: Build Error (Job 1205): sdlmame-0128-0_7_0127u7_fc9 on fedora-9-rpmfusion_nonfree
by Julian Sikorski
rpmfusion-buildsys(a)lists.rpmfusion.org pisze:
> Job failed on arch i386
>
>
> Build logs may be found at http://buildsys.rpmfusion.org/logs/fedora-9-rpmfusion_nonfree/1205-sdlmam...
>
>
> -------------------------------------------------
>
> ensuring dir /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/var/tmp
> ensuring dir /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/etc/yum.repos.d
> ensuring dir /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/proc
> Executing /usr/sbin/mock-helper mount -t proc proc /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/proc
> ensuring dir /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/pts
> Executing /usr/sbin/mock-helper mount -t devpts devpts /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/pts
> Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/null -m 666 c 1 3
> Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/urandom -m 644 c 1 9
> Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/random -m 644 c 1 9
> Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/full -m 666 c 1 7
> Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/ptmx -m 666 c 5 2
> Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/tty -m 666 c 5 0
> Executing /usr/sbin/mock-helper mknod /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/zero -m 666 c 1 5
> ensuring dir /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/etc/yum
> ensuring dir /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/proc
> Executing /usr/sbin/mock-helper mount -t proc proc /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/proc
> mount: proc already mounted or /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/proc busy
> mount: according to mtab, proc is already mounted on /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/proc
> ensuring dir /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/pts
> Executing /usr/sbin/mock-helper mount -t devpts devpts /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/pts
> mount: devpts already mounted or /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/pts busy
> mount: according to mtab, devpts is already mounted on /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/pts
> Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root groupinstall buildsys-build
> http://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora/linux/updates/9/i386....: [Errno 4] IOError: <urlopen error (-3, 'Temporary failure in name resolution')>
> Trying other mirror.
> Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora-updates-newkey. Please verify its path and try again
> Cleaning up...
> Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/proc
> Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-9-i386-rpmfusion_nonfree-2ef22792b2d72744ff0d7d0e51484fc60fc27fae/root/dev/pts
> Done.
>
This is happening since yesterday. Could anybody please look into it?
Thanks!
Julian
15 years, 6 months
