Re: Kernel-2.6.31.6-134 seems to have a bug on R600 DRM
interestingly i just updated a radeon hd4650 box to latest rawhide and the same error pops up again: [drm:r600_cs_packet_next_reloc_mm] *ERROR* No packet3 for relocation for packet at 45. [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014 [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! kind regards, Rudolf Kastl -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Upstart 0.6.3 coming to a rawhide near you
Why aren't the sysVinit scripts being ported over to native upstart scripts? I thought the reason why upstart was adopted was to be able to utilize the benefits of native upstart scripts (event based daemon handling, etc.)? No one is holding you back from starting to convert them now, but the format is most probably going to change again till the 1.0 release. Happy porting to you. ;) kind regards, Rudolf Kastl -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12 Graphics Issues: Cancel F13 and concentrate on fixing F12 ?
2009/11/26 Terry Barnaby ter...@beam.ltd.uk: Ok, controversial title. I have just tried to test install F12 on some of my systems, (5 different ones). All of these bar 1 has problems with the graphics (X11 lockups, system lockups and other problems) mainly in 3D but also in 2D. I still am using F8 on most of my systems as the Graphics systems have not been stable enough for 3D in Fedora since around those times. which cards exactly did you try? which drivers do you use... and what are the bugzilla bug numbers? As an idea, at this stage, how about canceling the F13 release and just fixing and updating the F12 release ? This will concentrate developers and users into one system release. Similar to the pre-release test days we could have post-release test days. For example a Graphics test day for F12 where a certain set of tests with a test suite and a set of well known applications could be run. As F12 would be out longer, more people could participate in this. i dont see the point because that will definitely lead to new regressions in f12 and annoy other people. interested partys can at any time of the development cycle test the current state of development (aka rawhide) and report and fix bugs in it. my personal experience is: intel (i965) works fine... there are some problems with shaders i have to investigate and there is a problem with interlaced resolutions. even displayport output works (hooked up to a fullhd tv via displayport - hdmi adapter) radeon 4650 works fine... even 3d works to some extent with the experimental dri drivers testing a new mesa build from koji even fixed various issues with 3d games i had left... also some effects/shaders seem to be not properly implemented yet... but hey... it is experimental) nvidia: nouveau kernel mode setting works and 2d experience is alot better already. 2d works in all setups i have personally tested. 3d still requires some progress but i dont see how it helps to stay on one release to get them resolved. kind regards, Rudolf Kastl If a commitment, all round, to producing updates fixing the issues in F12 were made, I think more people would be willing to participate as users could expect to see a stable system for their efforts. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
Actually it is a pity to usually see those convos drift off with arguments like but my computer has Actually besides for netbooks 32bit is legacy. sure there is old hardware around and there is still 32bit fedora but with that analogy... none of them work on my c64 anyways.. and yea i know many people that still have one (- really true!) jokes aside... i find kevin koflers idea yet the best posted solution. Even the most boring arguments like the fact that in the past 2 popular proprietary browser plugins didnt work on 64bit platform none of them are true anymore. (from my pov that was never really a blocker because i am the opinion that a few proprietary things shouldnt stop a huge open source project from progressing ahead). 64bit works since ages (actively using it since 4 years+) and these days most of the development focus should be on modern hardware, because this project is leaping ahead into the future and 32bit is largely the past. btw... you dont need to buy a netbook to get the performance benefits of an ssd. *writing that on f12 64bit on a lenovo x301 with ssd*, and no... ssds are not a step back but a leap ahead in many regards: power consumption, read performance, no seek times, close to no heat generation and no moveable parts (so no head crashes when you run around with the laptop.) - but that wasnt the real topic this thread was initially about. kind regards, Rudolf Kastl -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
conflict between seedit - selinux-policy and qstat - torque-client
Why do those packages have to conflict with each other?
1. seedit and selinux-policy-{targeted,mls} - i dont see a single
file conflicting atleast with the targeted policy...
2. qstat and torque-client both provide a qstat binary... is there
anything done to get that resolved upstream? or is it a conflicts and
forget scenario?
from my personal pov conflicts should be resolved instead of just
marked so things can be properly installed in parallel. everything
else looks broken to me.
kind regards,
Rudolf Kastl
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between seedit - selinux-policy and qstat - torque-client
2009/11/4 Jason L Tibbitts III ti...@math.uh.edu: ST == Steve Traylen steve.tray...@cern.ch writes: ST Would be happy for an alternatives solution. I have yet another ST /usr/bin/qstat for a POSIX interface to batch on the way at some ST point. Turns out that the other queuing systems (torque and gridengine) have already renamed their qstat binaries (to qstat-torque and qstat-ge). I would expect that other queuing packages should do the same. that means that the conflict tags in the qemu and the torque-clients package are invalid. thanks for checking jason! kind regards, Rudolf Kastl - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between seedit - selinux-policy and qstat - torque-client
2009/11/4 Steve Traylen steve.tray...@cern.ch: On Wed, Nov 4, 2009 at 4:11 PM, Rudolf Kastl che...@gmail.com wrote: 2009/11/4 Jason L Tibbitts III ti...@math.uh.edu: ST == Steve Traylen steve.tray...@cern.ch writes: ST Would be happy for an alternatives solution. I have yet another ST /usr/bin/qstat for a POSIX interface to batch on the way at some ST point. Turns out that the other queuing systems (torque and gridengine) have already renamed their qstat binaries (to qstat-torque and qstat-ge). I would expect that other queuing packages should do the same. Yes a qstat-slurm with qstat as alternative across them. Good news. but then the alternatives qstat conflicts with /usr/bin/qstat from the qstat rpm package, doesent it? kind regards, Rudolf Kastl that means that the conflict tags in the qemu and the torque-clients package are invalid. thanks for checking jason! kind regards, Rudolf Kastl - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Steve Traylen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between seedit - selinux-policy and qstat - torque-client
2009/11/4 Steve Traylen steve.tray...@cern.ch: On Wed, Nov 4, 2009 at 4:33 PM, Rudolf Kastl che...@gmail.com wrote: 2009/11/4 Steve Traylen steve.tray...@cern.ch: On Wed, Nov 4, 2009 at 4:11 PM, Rudolf Kastl che...@gmail.com wrote: 2009/11/4 Jason L Tibbitts III ti...@math.uh.edu: ST == Steve Traylen steve.tray...@cern.ch writes: ST Would be happy for an alternatives solution. I have yet another ST /usr/bin/qstat for a POSIX interface to batch on the way at some ST point. Turns out that the other queuing systems (torque and gridengine) have already renamed their qstat binaries (to qstat-torque and qstat-ge). I would expect that other queuing packages should do the same. Yes a qstat-slurm with qstat as alternative across them. Good news. but then the alternatives qstat conflicts with /usr/bin/qstat from the qstat rpm package, doesent it? The torque spec is creating correctly /usr/bin/qstat as a symlink via alternatives mechanism (reading the .spec only, have not checked). The qstat pkg should do the same. Currently while the qstat pkg is creating a file at /usr/bin/qstat then it is conflicting in the RPM sense. Once qstat pkg uses alternatives as well it will no longer conflict. Two packages that contain alternatives for a single file don't conflct in the RPM sense. You can install both pkgs and then select one to be the real /usr/bin/qstat via the alternatives mechanism. Hope that makes sense. it does with one exception... the qstat rpm is basically quake stat. so it does something completly different than the qstat of torque or gridengine and hmm the real resolution would maybe be to rename the binary of the qstat package then. kind regards, Rudolf Kastl p.s. thanks everyone for the replies and the effort done already. Steve kind regards, Rudolf Kastl that means that the conflict tags in the qemu and the torque-clients package are invalid. thanks for checking jason! kind regards, Rudolf Kastl - J -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Steve Traylen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Steve Traylen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between seedit - selinux-policy and qstat - torque-client
bug against qstat filed: https://bugzilla.redhat.com/show_bug.cgi?id=533016 as for seedit: i am going to investigate it further. kind regards, Rudolf Kastl -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: conflict between seedit - selinux-policy and qstat - torque-client
2009/11/4 Bill Nottingham nott...@redhat.com: Because seedit getting installed causes selinux-policy-targeted and friends to get screwed up. That sounds like a reason to not ship seedit. Am I missing something? on first start of the seedit-gui there is a popup: you have to initialize before using selinux policy editor. and policy is replaced with seedits original policy. if ok press initialize button there is no cancel button... but you can close that popup window. actually this looks like a bad idea and terrible design to me. why do i have to replace my workstations default policy to use the editor? *shrugs* kind regards, Rudolf Kastl Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB2 In Fedora
2009/11/3 Liang Suilong liangsuil...@gmail.com: Some Linux distros has migrated from grub-0.97 to grub2-1.97. Grub2 provides more useful features to users. And it is more easy to add a new file system support. But I can not see Fedora has any plan for GRUB2. I read a feature page on Fedora wiki. There is no progress on grub2. Now Fedora official repo offers grub2 package. However the version is quite strange. Fedora provides grub2-1.98. In fact, this version was 1.96 grabbed from svn repo on Aug 27th, 2008. Also, maintainer adds some patches to fix the bug. But GNU released grub2-1.97 just now. In addition, I try to write grub2 into MBR of the HDD. I do not know why. Is there a bug in grub2? -- urlhttp://www.liangsuilong.info/url Fight for freedom(3F） Ask not what your Linux distro can do for you! Ask what you can do for your Linux distro! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list see: http://fedoraproject.org/wiki/Features/Grub2 as for the outdated version... feel free to open a bug ticket and request an update to the latest stable version of grub2. kind regards, Rudolf Kastl -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
idea: abrt plugin for yum rpm scriptlets output
Hello! While doing some tests and installing a large part of the rawhide repository content i see that there are various packages that have a broken %post scriptlet or it is outputting some warnings. maybe it would be an idea for a abrt-yum plugin to submit those warnings and errors to bugzilla. unfortunately yum.log doesent record them either. that could definitely help in keeping the house clean i guess. kind regards, Rudolf Kastl -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: olpc components in x86/x86_64 repo
2009/10/7 Peter Robinson pbrobin...@gmail.com: On Wed, Oct 7, 2009 at 8:12 AM, Rahul Sundaram sunda...@fedoraproject.org wrote: On 10/06/2009 05:35 PM, Jon Ciesla wrote: Additionally, having OLPC-specific RPMS in mainline Fedora helps with the end goal that is , as I understand it, to have OLPC's OS be essentially a Spin of stock Fedora. It also helps OLPC devs who don't necessarily have XOs. IIRC, they already are shipping stock Fedora in their latest builds except for the kernel. They are also responsible for the largest amount of Fedora deployments in the world. So it is all mutually beneficial. That is correct, we're all upstream now with no weird branches for core packages :-) Thats great to hear and interesting information. In no way the question was meant as criticism. Basically i was just curious if the packages are hardware related to the olpc hw or generally useful. Thanks for your answer. Best wishes for the olpc/sugar developers. More knowledge and therefor power to the poor kids. kind regards, Rudolf Kastl Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
olpc components in x86/x86_64 repo
yum list all |grep olpc dracut-modules-olpc.x86_64 0.2.1-2.fc12 rawhide olpc-contents.x86_642.6-2.fc12 rawhide olpc-library.noarch 2.0.2-2.fc12 rawhide olpc-netutils.noarch0.7-4.fc12 rawhide olpc-switch-desktop.noarch 0.6-2.fc12 rawhide olpc-update.noarch 2.20-1.fc12rawhide olpc-utils.x86_64 1.0.3-2.fc12 rawhide does it really make sense to have those modules available on x86/x86_64? (this is from rawhide) kind regards, Rudolf Kastl -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: olpc components in x86/x86_64 repo
2009/10/6 Peter Robinson pbrobin...@gmail.com: On Tue, Oct 6, 2009 at 10:59 AM, Rudolf Kastl che...@gmail.com wrote: yum list all |grep olpc dracut-modules-olpc.x86_64 0.2.1-2.fc12 rawhide olpc-contents.x86_64 2.6-2.fc12 rawhide olpc-library.noarch 2.0.2-2.fc12 rawhide olpc-netutils.noarch 0.7-4.fc12 rawhide olpc-switch-desktop.noarch 0.6-2.fc12 rawhide olpc-update.noarch 2.20-1.fc12 rawhide olpc-utils.x86_64 1.0.3-2.fc12 rawhide does it really make sense to have those modules available on x86/x86_64? (this is from rawhide) Yes, because they are used on both x86 and x86_64 platforms. What is the problem having them there? Peter somehow i had the impression they are atleast partially related to the olpc hardware. kind regards, Rudolf Kastl -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Best Linux distros for power users, gamers, newbies and more
2009/5/12 Ankur Sinha sanjay.an...@gmail.com: hi, Firstly, Fedora just looks better, despite being built around the same Gnome desktop as Debian. The astronomical theme that accompanies you while you launch the operating system is carried on to the blue desktop, and there's a distinct feeling that a lot of love has gone into Fedora's default theme. well it is just a theme though. and themes are a matter of taste. i am not sure if that is a good argument for the topic best for power users, gamers, newbies. from my pov a real power user doesent waste resources on wallpapers. but oh well. Secondly, Fedora manages to include OpenOffice.org 3, while Debian is still a revision behind, and Fedora's version of Firefox keeps the original branding, rather than the confusing rebranding of all things Mozilla insisted on by the Debian developers. Different target audience and release cycle. Personally i find it quite neat that the debian guys dont do compomises on things like trademarks. For every day desktop use, Fedora can't be beaten. The choice of software is excellent, and we can't think of anything that's missing. Fedora's stance on freedom is a little painful if you need proprietary drivers or MP3 support, but these issues can be worked around. errm... no comment, btw the debian repositorys still hold alot more content. a few years ago linux power users still cared about freedom. dont get me wrong... i am a long time redhat/fedora user, but i just dont see any really good arguments in the article above... why a power user, gamer or newbie would want to choose fedora instead debian (the headline claims best linux distro but in the end it seems to be a fedora vs debian thingie) kind regards, Rudolf Kastl :D http://www.techradar.com/news/software/operating-systems/best-linux-distros-for-power-users-gamers-newbies-and-more-596697?artc_pg=3 regards, Ankur -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Cool install Icons?
2008/12/5 Nicu Buculei [EMAIL PROTECTED]: Scott Baker wrote: Would it be possible to resurrect something silly like that during the install? The current install images aren't nearly as exciting. Honestly I couldn't even tell you what they say! But I *do* remember those hotdog install screens from all the way back in RH8/9 from six years ago. That's good marketing! This was talked a few times in the past: we still have the hooks in Anaconda, Art would be interested to try something, Marketing may be interested in using this promo venue... we didn't had someone to take leadership on it. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list the way it is now though it looks very professional and polished. (sure a subjective taste question) kind regards, Rudolf Kastl -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Introducing Fedora Nightlife
On Thu, May 29, 2008 at 7:55 AM, Rahul Sundaram [EMAIL PROTECTED] wrote: Hi, http://bryanche.blogspot.com/2008/05/introducing-fedora-nightlife.html Fedora Nightlife is a new project for creating a Fedora community grid. People will be able to donate idle capacity from their own computers to an open, general-purpose Fedora-run grid for processing socially beneficial work and scientific research that requires access to large amounts of computing power. http://digg.com/linux_unix/Introducing_Fedora_Nightlife Rahul irc channel #fedora-nightlife is open on irc.freenode.net for those interested. kind regards, Rudolf Kastl -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: new list of names for fedora grid project
#fedora-nightlife on irc.freenode.net is open :D kind regards, Rudolf Kastl -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: new list of names for fedora grid project
#fedora-nightlife on irc.freenode.net is open for business kind regards, Rudolf Kastl -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Fedora Life Cycle
2007/10/23, Rodrigo Padula de Oliveira [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rahul Sundaram escreveu: Rodrigo Padula de Oliveira wrote: Do you have any idea of what i'm talking about How can they update it every six month?? It's a craziness !! It involves planning and a lot of work! it's not that simple! They don't have to upgrade just because we have a new release. They can upgrade every 13 months or so instead. Just something I thought I would highlight better. And They can not enjoy the innovations? Let's go! - - Fedora is released - - 1 or 2 months packing and releasing new and necessaries packages versions ( now we have 11 months). - - 1 or 2 months planning, studying the impacts, creating the migration plan and applying it(now we have 9 months) - - o in 9 months we have to do this again - - so, we will use CENTOS or DEBIAN. 1. Requirement Analysis 2. Evalution of alternatives 3. Pick the distribution best suited for the task at hand and start planning So you just figured out fedora doesent meet your or your customers requirements and you are not a member of the intended audience with running a production server with fedora then fine... there are enough alternatives better suited for the task. just proposing that fedora should be yet another distribution that moves very slowly (there are enough of those available) isnt very productive. regards, Rudolf Kastl That is the problem! Year by year migrating all fedora systems to the new version! Rahul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHHepAPg3HAC1vlg4RAmNWAJ4wEXucqCmdkD32H0SDM1yicUeMBACfXYJt Hh0A4qFIG/7BE1nTdFBI5+s= =LIx1 -END PGP SIGNATURE- -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Fedora derivatives branding discussion
2006/4/20, Jeff Spaleta [EMAIL PROTECTED]: On 4/20/06, Jesse Keating [EMAIL PROTECTED] wrote: But what about when the Fedora Red Hat ships is an amalgum of some packages within the Universe (I hate this word)? Is it only a REAL Fedora when it comes out of Red Hat? Things reviewed and blessed by the Fedora Board get access to the more restricted marks. As in a live-cd that the board reviews and blesses.. gets access to the more restricted marks and don't need to claim based on. but can still claim based on. A livecd thats been built from Core+Extras sources but not reviewed/blessed by the board must use based on and uses the less restricted mark. If Red Hat wants to ship an amalgum that doesn't get reviewed and blessed by the Fedora Board... then no.. they dont get to use the more restricted mark... neener neener neener. hi |jef| i think thats a pretty good idea of dealing with things in a fair way. but just a question... what if i add a single package that isnt yet in extras nor core... am i not allowed to call it based on fedora with only minor changes that are documented in a clean way? with having a distro that is 99,9% fedora (e.g. a live cd... e.g. with distcc...) wouldnt it be still based on fedora from a pure technical point of view? How would i be able to call that live cd then? regards, Rudolf Kastl -jef -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Fedora derivatives branding discussion
2006/4/20, Jesse Keating [EMAIL PROTECTED]: On Thu, 2006-04-20 at 20:03 +0200, Rudolf Kastl wrote: but just a question... what if i add a single package that isnt yet in extras nor core... am i not allowed to call it based on fedora with only minor changes that are documented in a clean way? with having a distro that is 99,9% fedora (e.g. a live cd... e.g. with distcc...) wouldnt it be still based on fedora from a pure technical point of view? How would i be able to call that live cd then? That is no longer based on Fedora. That includes parts of Fedora, but adds to it, and thus cannot be claimed to be Fedora. Get the package in Extras (; but its still derived from fedora isnt it? distcc is hanging idle in bugzilla for ages :) someone finish the review. regards, Rudolf Kastl -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBER84+4v2HLvE71NURAvs8AJ9rRMEFj7UlWdPFSfuOFkwZc1HfiQCgvL/Z F7w4E343p6FGl6TEZjrxejc= =Efy5 -END PGP SIGNATURE- -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Fedora derivatives branding discussion
2006/4/20, Andre Nogueira [EMAIL PROTECTED]: On 4/20/06, Jesse Keating [EMAIL PROTECTED] wrote: That is no longer based on Fedora. That includes parts of Fedora, but adds to it, and thus cannot be claimed to be Fedora. Get the package in Extras (; That also solves the problem of a distro wanting to use proprietary software (which isn't acceptable in Fedora), while the rest is based on Fedora. (Eg, a distro which includes Acrobat Reader, but appart from that only includes Fedora packages). Otherwise, how would you distinguish an almost Fedora-based distro which includes proprietary packages, from another which includes free packages that are not in Fedora or Fedora Extras? Thanks, Andre well that was exactly my question... what terms are legal... i am neither a lawyer nor do i want to consult one at this point :). regards, Rudolf Kastl -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Fedora derivatives branding discussion
2006/4/20, Jesse Keating [EMAIL PROTECTED]: On Thu, 2006-04-20 at 20:19 +0200, Rudolf Kastl wrote: but its still derived from fedora isnt it? distcc is hanging idle in bugzilla for ages :) someone finish the review. No, because (as Max forgot to mention) the Based on Fedora must be based on the Binary packages, not rebuilds of the source packages. No published Binary, can't use it. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBER9GC4v2HLvE71NURAuNaAJ9wuKem64SyF0ADSH9uyxt4khiRgACgkyEy /f7+cbIOoFFKRLNGYMXOUNQ= =U6nE -END PGP SIGNATURE- -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list id have to remove all art and branding etc... ok... but then again calling it derived of fedora is legal? i am still just curious... sorry for keeping on asking the same question. is only fork of fedora legal then? -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: Wild and crazy times for the development tree
2006/3/21, Hans Kristian Rosbach h...@isphuset.no: On Mon, 2006-03-20 at 23:29 -0600, Callum Lerwick wrote: On Mon, 2006-03-20 at 23:11 -0500, Dave Jones wrote: DVD writers aren't anywhere near as commonplace as CD writers yet. Looking around right now, I have 7 computers near me. CD writers outnumber DVD writers 6:1. (And the majority of the computers with CD writers are less than 2 years old (two of them are 6 months old)) (ironically, the dvd writer is my 3 month old laptop) Yeah, but you own at least one, and that's the point. Extend this to friends with DVD writers. How many people don't have one? This does not hold in all cases. For example take any server hosting company, at least here the cd-roms outnumber the dvd-roms approx 15:1 at the moment. All new servers gets dvd-roms, but we don't want to exchange several hundred cd-roms into dvd-roms. Besides I hardly ever need more than cd1 on those servers due to the post-install script fetching most useful packages so I only need to do a minimal install on all servers no matter what purpose they will have. And then at home, I have dvd-roms in all my workstations but my mother (and many others that I help out at times) does not. So i would still need to carry the cd version as that is universally usable. For that reason I have never even downloaded a single FC dvd image yet. My firewall and all development boxes have only cd-roms as most of them are P2/P3/Xeon 700Mhz, and even my dual Xeon 2.8Ghz has a cd-rom. -HK -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list do you go to every server in your rack and pop in an install cd/dvd? :) you serious? regards, rudolf kastl
Re: Wild and crazy times for the development tree
2006/3/21, Hans Kristian Rosbach h...@isphuset.no: On Tue, 2006-03-21 at 12:50 +0100, Rudolf Kastl wrote: do you go to every server in your rack and pop in an install cd/dvd? :) you serious? Since we install about 1-3 servers per week, yes. (And I don't have to do any of the carrying) 1. Server arrives at workshop desk 2. Hardware is installed/upgraded/dusted off 3. Bioses/firmwares updates 4. Memtest86+ overnight 5. OS Install (type depending on customers or our needs) 6. Server placed into rack This lets us spot failing hardware such as capacitors or hear noisy disks/fans. And with the KVM extender to my office I can administrate the install remotely when I come into my office after the overnight memtest anyways. It might possibly be a bit more work than booting off PXE but then we would have the added administration of PXE image servers on each physical net. And just generally a cdrom is a whole lot easier to debug if something fails. Installing minimal images over PXE would of course save more time, but I would still have to make and maintain all of them. (Another benefit is that the firewall in that room is set up such that windows servers don't get viruses on them before windows update has run.) -HK -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list yup i was thinking of an install server. there are various approaches as to how to do deal with it of course. well actually if you think your present approach is best regarding your use case i wont hold you back. personally id go for the above mentioned pxe solution and push a hd install then. regards, Rudolf Kastl
Re: An idea re ambassadors
2006/3/21, Filip Tsachev [EMAIL PROTECTED]: -jef sample flyer Interested in learning about Fedora Linux? Are you a HOT chick? Then contact [EMAIL PROTECTED] for personal lessons on using Fedora /sample flyer spaleta That almost killed me :D. Seriously Jef, start publishing those signatures -- Cheers, Filip http://fedoraproject.org/wiki/FilipTsachev -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list wheres fortune-jef ? ;) -- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-marketing-list
Re: username best practices and other conventions
2006/3/6, Karel Zak k...@redhat.com: On Thu, Mar 02, 2006 at 04:21:12PM +, Joe Desbonnet wrote: I think it's time to move beyond those traditional limits. At some point we got over the 14 char file name limits, and the world is a better place for it. I much prefer to spend a few more characters for clarity. Eg Hmm.. spend for what? For example ps aux uses all terminal columns and on traditional terminal with 80 columns there will be less space for the command column. So we will lost a lot of useful information about all processes, because there is one process that running with obscure username. I think 8 chars is good compromise. BTW, if you want to see full usernames you can use: ps -eo user:14,pid,%cpu,%mem,vsz,rss,tty,stat,start_time,time,command IMHO, Fedora should respect the traditional best practices and conventions (not speaking solely about usernames) and not violate them without good reason. It seems there is maybe a carefree indifference or possibly ignorant attitude about the old ways. Breaking long standing conventions in itself violates the principal of least surprise -- something sys admins do not care for. Agree. distcache = 9 haldaemon = 9 nfsnobody = 9 webalizer = 9 beagleindex = 11 Please, fill bugzilla. Karel -- Karel Zak k...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list this sounds to me like going back to 8 char filenames again. best practice with the limitations of the last decade ... i dont know if thats the right approach... if a console command has problems to deal with proper output id fix the command. just my opinion. Using cryptic names also makes stuff less obvious with no real gain in my eyes besides working around some limitations of console commands maybe as described above. regards, Rudolf Kastl
nvidiafb
Hello! I am well aware that the nvidiafb/rivafb driver doesent work well together with the nvidia binary driver... that said... id be happy if nvidiafb would be built aswell. as far as i know and read it should be in the mainline kernel but it seems that the module isnt built in latest fedora development kernels, rivafb is. I am not really aware about the details regarding this issue or feature request but is there a sound reason why the nvidiafb driver isnt beeing built so one could atleast test it? regards, Rudolf Kastl p.s. radeonfb on my thinkpad works great ;)
Re: games user and group
Horst H. von Brand wrote: This means the overloaded user has to remember to mark as used the stuff she is using so it doesn't get pulled out from under her feet by deleting unrelated packages. Nobody said stuff has to be removed automatically. After you have a working infrastructure, you can decide the default behavior. # yum remove a) b) Packages to be removed: a) b) Proceed:(y/n) y 2 packages removed. # yum list --unused-deps The following packages were installed for dependencies but are currently not needed (use 'remove --unused-deps' to remove them): c) d) # yum remove --unused-deps Packages to be removed (unused deps): c) d) Proceed:(y/n) y 2 packages removed. (just fictional messages, of course) -- Roberto Ragusamail at robertoragusa.it -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
