rawhide report: 20070409 changes
by Build System
Updated Packages:
(none)
Broken deps for ppc64
----------------------------------------------------------
gimp - 2:2.2.13-2.fc7.ppc64 requires gimp-print >= 0:4.2.0
perl-LDAP - 1:0.34-2.fc7.noarch requires perl(Net::LDAP::Filter)
xdoclet - 1.2.3-7jpp.2.ppc64 requires mockobjects
Broken deps for x86_64
----------------------------------------------------------
gimp - 2:2.2.13-2.fc7.x86_64 requires gimp-print >= 0:4.2.0
perl-LDAP - 1:0.34-2.fc7.noarch requires perl(Net::LDAP::Filter)
xdoclet - 1.2.3-7jpp.2.x86_64 requires mockobjects
Broken deps for i386
----------------------------------------------------------
gimp - 2:2.2.13-2.fc7.i386 requires gimp-print >= 0:4.2.0
perl-LDAP - 1:0.34-2.fc7.noarch requires perl(Net::LDAP::Filter)
xdoclet - 1.2.3-7jpp.2.i386 requires mockobjects
Broken deps for ppc
----------------------------------------------------------
gimp - 2:2.2.13-2.fc7.ppc requires gimp-print >= 0:4.2.0
perl-LDAP - 1:0.34-2.fc7.noarch requires perl(Net::LDAP::Filter)
xdoclet - 1.2.3-7jpp.2.ppc requires mockobjects
Broken deps for ia64
----------------------------------------------------------
gimp - 2:2.2.13-2.fc7.ia64 requires gimp-print >= 0:4.2.0
perl-LDAP - 1:0.34-2.fc7.noarch requires perl(Net::LDAP::Filter)
xdoclet - 1.2.3-7jpp.2.ia64 requires mockobjects
17 years, 1 month
FESCo Meeting Summary for 2007-04-05
by Brian Pepple
=== Members Present ===
* Brian Pepple (bpepple)
* Jason Tibbitts (tibbs)
* Christian Iseli (c4chris)
* Rex Dieter (rdieter)
* Toshio Kuratomi (abadger1999)
* Kevin Fenzi (nirik)
* Dennis Gilmore (dgilmore)
* Warren Togami (warren)
* Josh Boyer (jwb)
* Jeremy Katz (jeremy)
* Jesse Keating (f13)
=== Absent ===
* Tom Callaway (spot)
* Bill Nottingham (notting)
== Summary ==
=== Packaging Committee Report ===
* Packaging Committee didn't have any guidelines that needed FESCo
approval this week.
=== cvs-import changes ===
* Jens Petersen's patch has been applied, and c4chris will send a
message to the mailing list informing them of the change.
=== Package Database ===
* abadger1999 is looking for help in writing some small scripts, mainly
adaptations of things currently using owners.list. If you interested,
please contact Toshio.
=== Package Conflicts ===
* bpepple will contact Michael Schwendt to see if he has a tool to help
identify packages with conflicts, and if he is also interested in
helping to fix them.
=== F7 Preparation ===
* It was discussed what deadlines we should have for EVR and broken
deps. It was suggested that they should be fixed a week before F7t4,
otherwise they would be removed. nirik will send a message to the
mailing-lists informing the maintainers of this.
* Discusses the problem with Zope/plone since it is unable to work w/
Python-2.5. It was decided that pull Zope/plone for F7, rather than
push a compat python package. For details on the lengthy discussion of
this, please refer to the IRC log.
For full IRC log:
http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070405
Thanks,
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
17 years, 1 month
Announcing RUM: offline update/install tool for YUM/RPM based systems.
by Debarshi Ray
I had in an earlier mail discussed the possibility of writing a
separate tool, or an enhancement to YUM or Pirut for offline
update/installation of packages on YUM/RPM based systems, specifically
Fedora.
This formed the basis of my application to Google Summer of Code 2007.
You may find a copy of the proposal at:
http://glug-nith.org/~rishi/download/soc/soc-proposal-fedora-offline
Just to find out whether the back-end work of managing the profiles,
and handling the yum-packs was going to be possible with the existing
tool-set, I wrote a BASH script to do the job. No GUI, just a rough
idea of the functionality. You can read more about it here:
http://www.ilug-cal.org/wiki/index.php/RUM while the code is available
at http://glug-nith.org/~rishi/download/src/rum.sh
However I would like to bring to your attention a few of my
observations. Firstly I understand that YUM does not support the
facility of *just* downloading the packages and *not* installing them.
The idea it seems is to let yumdownloader to do the job. The problem
is that although yumdownloader is able to download packages, its
--resolve option does not work. See
https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=702 Moreover how
can I ask yumdownloader to consult a different rpmdb than the default
one at /var/lib/rpm?
I am a bit curious to know why it is deemed inappropriate to have this
feature in YUM itself? I do not want to be rude, but isn't it just a
simple task of checking a command line option before actually starting
to install the packages? Right now I have to use the --installroot
option to force YUM to install to a different rpmdb and then delete
everthing after extracting the packages downloaded to
<new_root>/var/cache/yum/*packages/*.rpm to create the yumpack. This
looks messy to me.
Thanks,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
17 years, 1 month
Problem with installing the nvidia drivers
by Mark
Hey,
i normally find it hard to install the nvidia drivers because there is no
"official" fedora way.. it all has to be done with the livna repository.
but now i`m getting very strange problems..
I install the kernel module driver and the xorg nvidia driver:
kmod-nvidia-1.0.9755-1.2.6.20_1.3045.fc7
xorg-x11-drv-nvidia-1.0.9755-2.lvn7
than i run x. at this moment i have nvidia and all seems to be running
fine.. untill i restart.
somehow everything that is installed by:
xorg-x11-drv-nvidia-1.0.9755-2.lvn7is not on my disc anymore once i
restarted..
i have no idea what could cause this problem..
how do you all install the nvidia drivers? i have a 6800 GT
17 years, 1 month
Re: rpms/knetworkmanager/devel .cvsignore, 1.5, 1.6 knetworkmanager-kpp.patch, 1.1, 1.2 knetworkmanager.spec, 1.6, 1.7 sources, 1.5, 1.6
by Ville Skyttä
On Monday 09 April 2007, Dennis Gilmore wrote:
> +%files devel
> +%{_includedir}/knetworkmanager-plugin.h
> +%{_includedir}/knetworkmanager-vpnplugin.h
> +
> +%files openvpn
> +%{_libdir}/kde3/knetworkmanager_openvpn.la
> +%{_libdir}/kde3/knetworkmanager_openvpn.so
> +%{_libdir}/kde3/knetworkmanager_openvpn.so.0
> +%{_libdir}/kde3/knetworkmanager_openvpn.so.0.0.0
> +%{_datadir}/services/knetworkmanager_openvpn.desktop
> +
> +%files vpnc
> +%{_libdir}/kde3/knetworkmanager_vpnc.la
> +%{_libdir}/kde3/knetworkmanager_vpnc.so
> +%{_libdir}/kde3/knetworkmanager_vpnc.so.0
> +%{_libdir}/kde3/knetworkmanager_vpnc.so.0.0.0
> +%{_datadir}/services/knetworkmanager_vpnc.desktop
> +
> +%files pptp
> +%{_libdir}/kde3/knetworkmanager_pptp.la
> +%{_libdir}/kde3/knetworkmanager_pptp.so
> +%{_libdir}/kde3/knetworkmanager_pptp.so.0
> +%{_libdir}/kde3/knetworkmanager_pptp.so.0.0.0
> +%{_datadir}/services/knetworkmanager_pptp.desktop
%defattr(-,root,root,-) missing from all these.
17 years, 1 month
Deadline for Summer of Code app reviews approaches
by Patrick W. Barnes
We need to finish evaluations on the Summer of Code applications before
Wednesday (2007-04-11 00:00 Pacific, 07:00 UTC). On Wednesday, the student
allotments will be finalized and we'll lose any applications that don't have
mentors assigned. Our current projected allotment is 6 projects, though we
might pick up extra slots if we have mentors assigned for more.
After my last call, we had several more people sign up to help review
(thanks!), but only a few have gone back and entered comments or evaluations.
While we could proceed with the evaluations we have so far, I think we'd all
be happier if we had stronger reviews of the proposals before making any
decisions. On Tuesday, I'll make any arbitrary decisions I have to in order
to accept the right proposals, and I'll assign mentors from among the
volunteers. I'll mentor as many students as I need to, but it would really
be best if each student had their own primary mentor with any number of
backup mentors. It doesn't take much to serve as a mentor, so please
volunteer if you see a proposal you like.
Once again, the necessary resources can be found from the wiki:
http://fedoraproject.org/wiki/SummerOfCode/Mentors
If you need help, please email me directly for the sake of speed.
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
http://n-man.com/
LinkedIn:
http://linkedin.com/in/nman64
Have I been helpful? Rate my assistance!
http://rate.affero.net/nman64/
--
17 years, 1 month
Re: New developer
by Vlad
Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
> It is not worth the effort for Anaconda and many other tools.
Sure, if you think KDE users aren't worth having an efficient Fedora
system. Loading two different graphic frameworks at the same time
wastes memory/diskspace, slows down startup time, and leads to
graphical inconsistencies. For people with low-end hardware that makes
a huge difference.
> There are other KDE focussed distributions which have used GTK based
> tools like Mandriva.
That's a suboptimal solution, originating from a lack of foresight in
designing those applications to separate the core functionality from
the GUI components. I would point to K/Ubuntu as an example where
desktop integration is tackled correctly: for every system tool there
is a KDE or GNOME frontend to be used on the respective desktop, and
the core functionality is shared in a common backend.
> If you disagree put in the effort.
The only reason I mentioned the lack of KDE frontends for system tools
in Fedora is that a potential developer with Qt background asked where
he can help.
Vlad
____________________________________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
17 years, 1 month
is mgetty being maintained?
by Don Russell
I originally posted this on "fedora-list", but was nudged to here as a
more appropriate list for this issue: :-)
mgetty on FC6 is at version 1.1.33-9 : 2005-04-10
I opened a new bug against it (
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232522 ) and in
doing some research to find the source code discovered there have been
two releases since then. Even the most recent is more than a yearold
now, but still not available via yum update.
1.1.34 : 2005-11-30
1.1.35 : 2006-02-22
Is mgetty still being maintained as a Fedora component? Is it deprecated
and there is a replacement I should use instead?
I was going to see if I can fix the problem, but for all I know it is
already fixed in one of these newer releases.
How do I request that mgetty be updated in FC6? I think the package
maintainer has gone walk about so opening a new bugzilla report seems
ineffective: Another bug (
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217844 ), created
2006-11-30 has never even been replied to. :-(
Which version will be in FC7? I can wait for FC7, that is only a month
or two away now.
Thank you.
17 years, 1 month