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
Re: other annoyances before fc5
2006/3/4, Jesse Keating : > On Sat, 2006-03-04 at 21:09 +, Vitor Domingos wrote: > > Btw, what's the status for suspend/hibernate on FC5, specially on ATI > > Radeon cards ? > > I'm on rawhide (with tuesday updates) and it still doesnt resumes Xorg > > properlly. > > My T42 laptop works great with its radeon mobility chip. > > Two things: I have acpi_serialize as a kernel arg in grub, and I have > radeonfb uncommented in /etc/modprobe.d/blacklist. Also I have options > radeonfb radeon_force_sleep=1 in /etc/modprob.conf. Suspend and > hibernate work great. i got a thinkpad r51 and suspend and hibernate also works great (with acpitool -S and acpitool -s). ati mobility resumes without problems. i have radeonfb turned on actually too. regards, rudolf kastl > > -- > Jesse Keating > Release Engineer: Fedora > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2.1 (GNU/Linux) > > iD8DBQBEChD+4v2HLvE71NURAmcxAJwLv1jLkfuN9uRLU7UZ5wtopuMQKwCfb3qU > c7Rl047lvGzl5RsKeFgbM/k= > =hpcJ > -END PGP SIGNATURE- > > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > >
Re: username best practices and other conventions
2006/3/6, Karel Zak : > 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 > > -- > 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: speed up Firefox start by a factor of 3 on x86
2006/3/17, Arjan van de Ven : > On Fri, 2006-03-17 at 08:38 +0100, Gianluca Cecchi wrote: > > On Thu, 16 Mar 2006 17:35:03 -0800 John Reiser wrote: > > >In contrast, Firefox always starts in 5 seconds or less on a kernel > > which places > > >the vDSO intelligently: > > I read the long list of your reports at the bugzilla page, with the > > many details and test cases provided, but apart the beginning, you > > pratically received no feedback at all (at least inside bugzilla > > itself): only periodically that "having merged with upstream kernel, > > more than thousands of changes, so please test again and let know..." > > I think you had better to submit your considerations to upstream kernel > > list. > > In this way if accepted, they would be naturally incorporated also in > > fedora. > > I'm not a kernel expert so sorry if this doesn't fit for you. > > Juest my 0.02 euros... > > > > that's not going to fly since this is a fix to a fedora specific > patch ;) > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > more comments on the fix would be nice. will it be merged? regards, rudolf kastl
Re: Wild and crazy times for the development tree
2006/3/21, Hans Kristian Rosbach : > 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: gnome 2.14 test updates
2006/3/20, Ray Strode : > Hi, > > On Mon, 2006-03-20 at 13:17 -0600, Jeffrey C. Ollie wrote: > > On Mon, 2006-03-20 at 12:44 -0500, Ray Strode wrote: > > > > > > A number of gnome 2.14 packages didn't quite make the FC5 cut. These > > > packages have been pushed into -updates-testing, now. For those > > > interested in helping, please give the new packages a test run and > > > report any problems you find with them. > > > > > > If all goes well we should be able to push the updates that don't cause > > > regressions into -updates in a few days. > > > > Have these packages been pushed to development as well? > Not yet. Although it will happen soon. > > --Ray > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Thats one thing i dont really understand. Actually all your hardcore testers are on rawhide. If things should be tested properly id personally expect that things hit rawhide and then the testing repos not vice versa. regards, Rudolf Kastl
Re: Wild and crazy times for the development tree
2006/3/21, Hans Kristian Rosbach : > 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: Possible packages...
2009/7/13 Adam Williamson : > On Sun, 2009-07-05 at 20:15 -0600, Nathanael Noblet wrote: > >> Apple's Calendar Server. It runs using python 2.5 or greater (I've >> installed it on a F11 machine and it work well). I've started looking >> at some of its dependancies. 90% of them are in fedora already, and of >> the ones in F11, only one if I remember correctly isn't at the version >> it requires). It seems like a great addition to Fedora if you ask me. >> So basically it would require two new packages, and an update to one >> other package (libevent) which is a minor version bump it seems if at >> all needed. > > The Infrastructure group has a rather ongoing project to try and find a > really good calendar server system (and then, obviously, package it) to > be used as the official Fedora calendaring system (then we could > schedule events and all that good stuff in an official Fedora server, > and people could access them via CalDAV or web, and all would be roses). > It's proved a bit tricky, though, to find a really perfect option. See > https://fedoraproject.org/wiki/Infrastructure/Test/Calendering_Solution > for most of the details on this project. At present, we seem to be > looking at one called Calagator: http://calagator.org/ . > >> PS3MediaServer. A Java program to talk to a PS3 with DLNA. I'm >> guessing this one would have problems because it requires ffmpeg or >> mplayer/mencoder... Plus as a java program its probably a bit more >> complex to create a proper spec file for. I've made the other kind >> often enough, but java ones not so much... > > There's a sort of 'agreed-upon-right-way-of-doing-this' candidate for > this particular need, which is a nice modern GTK+ app and based on > gstreamer...but I can't quite pull the name out of long-term storage at > present. Someone will probably know what I mean, though. The one most > people use (as the one I'm talking about is still a bit alpha) is > mediatomb, which is also in Fedora already. Unless this provides > something significant the other options don't, it may not be the best > place to start, since it looks a bit complex. ps3mediaservers biggest improvement/enhancement is the ability to transcode video files on the fly. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net > > -- > 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: Possible packages...
2009/9/17 Adam Williamson : > On Thu, 2009-09-17 at 09:52 +0200, Rudolf Kastl wrote: > >> >> PS3MediaServer. A Java program to talk to a PS3 with DLNA. I'm >> >> guessing this one would have problems because it requires ffmpeg or >> >> mplayer/mencoder... Plus as a java program its probably a bit more >> >> complex to create a proper spec file for. I've made the other kind >> >> often enough, but java ones not so much... >> > >> > There's a sort of 'agreed-upon-right-way-of-doing-this' candidate for >> > this particular need, which is a nice modern GTK+ app and based on >> > gstreamer...but I can't quite pull the name out of long-term storage at >> > present. Someone will probably know what I mean, though. The one most >> > people use (as the one I'm talking about is still a bit alpha) is >> > mediatomb, which is also in Fedora already. Unless this provides >> > something significant the other options don't, it may not be the best >> > place to start, since it looks a bit complex. >> >> ps3mediaservers biggest improvement/enhancement is the ability to >> transcode video files on the fly. > > Since I wrote the message quoted by Rudolf, I remembered the name of the > app I was trying to think of: Rygel - http://live.gnome.org/Rygel > > aside from that, the 'market leader' is mediatomb, which I think we have > in Fedora or RPM Fusion already. It has been able to do transcoding for > a long time, and there's a big knowledge base out there on how to use > it. I'm not entirely sure adding another packaged > ps3-intended-UPNP-server would be a net win anywhere. > > (unless ps3mediaserver's implementation of on-the-fly transcoding lets > you fast-forward and rewind. that'd be good. mediatomb can't do that.) no but it can use tsmuxer for just remuxing content if the video is h264 but the container cant be read by the ps. alrough tsmuxer isnt free enough (and it is bundled with ps3mediaserver) it would have to go to rpmfusion anyways if you want to have it around fully featured. Forward and rewind doesent work either but thats probably none of the streaming backends in use can do it (mencoder vlc etc). kind regards, Rudolf Kastl > > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net > > -- > 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 : > On Tue, Oct 6, 2009 at 10:59 AM, Rudolf Kastl 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: olpc components in x86/x86_64 repo
2009/10/7 Peter Robinson : > On Wed, Oct 7, 2009 at 8:12 AM, Rahul Sundaram > 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
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: GRUB2 In Fedora
2009/11/3 Liang Suilong : > 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? > -- > http://www.liangsuilong.info > 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
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 : >>>>>> "ST" == Steve Traylen 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 : > On Wed, Nov 4, 2009 at 4:11 PM, Rudolf Kastl wrote: >> 2009/11/4 Jason L Tibbitts III : >>>>>>>> "ST" == Steve Traylen 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 : > On Wed, Nov 4, 2009 at 4:33 PM, Rudolf Kastl wrote: >> 2009/11/4 Steve Traylen : >>> On Wed, Nov 4, 2009 at 4:11 PM, Rudolf Kastl wrote: >>>> 2009/11/4 Jason L Tibbitts III : >>>>>>>>>> "ST" == Steve Traylen 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 : >> 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: 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
Re: Security policy oversight needed?
there are also inconsistencies between gui clickery and shell usage... simple example: click "shutdown" in gnome just does it in f12 issuesing shutdown -h now on the shell asks for root password ... id really expect a system to show consistent behaviour not only in gui clickery but system wide. this feels pretty 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: Security policy oversight needed?
2009/11/20 Rudolf Kastl : > there are also inconsistencies between gui clickery and shell usage... > simple example: > > click "shutdown" in gnome just does it in f12 > > issuesing shutdown -h now on the shell asks for root password ... id > really expect a system to show consistent behaviour not only in gui > clickery but system wide. this feels pretty broken to me. to correct myself... it doesent directly prompt for it... but it whines that shutting down the box needs root privs... still the point is ... there are more and more inconsistencies intrudoced and that is not a good sign when it comes to security. kind regards, rudolf kastl -- 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 : > 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: 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: 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
