Re: Unable to install locally built rpms
On Wed, 2023-03-01 at 20:07 +0100, Ralf Corsépius wrote: > > Am 01.03.23 um 16:31 schrieb Adam Williamson: > > On Tue, 2023-02-28 at 09:10 +0100, Ralf Corsépius wrote: > > > Hi, > > > > > > on f38, I am unable to install any locally built package (signed > > > with a > > > local key, I have been using for many years): > > > > "Many years" is likely the problem. It's probably using SHA-1 or > > DSA. > > See, for e.g., > > https://bugzilla.redhat.com/show_bug.cgi?id=2170878 . Those are now > > known to be insecure. > > > > That bug covers some awkward problems with widely-used third parties > > still using insecure keys to sign their packages, which likely means > > this will get put off (one way or another) to at least Fedora 39. > > But > > for your own locally built packages, which are under your control, > > you > > can solve it permanently right now: generate a new key using a > > secure > > algorithm, and re-sign your packages with that. > > > > > What are people supposed to do? > > > > See above. > > Cf. the discussion on *-devel. > > Due to this list not being open, I do not see any sense trying to > furtherly discussing this issue here. > > Only one point concerning you and this list: It seems obvious to me, > this change was not tested at all. The effects of this change are > desasterous, Annoying, yes. Disastrous, no. Easiest solution is the one already discussed, your old key is never going to be accepted again so it is time to make a new one. Solved. Second solution is to revert Fedora's new paranoia that will detonate any old package. "sudo update-crypto-policies --set LEGACY" and get on with life for another Fedora release cycle... then the madmen will break things again. It is a cryptoweenie thing, break anything more than a few years old while autistically screeching "but it is INSECRE!" Be thankful, as bad as Fedora can be, OpenSSH is worse; when they do the "INSECURE!" screeching they eventually remove every line of code that supported the now insecure crypto so you can't even rebuild from source to be able to still talk to that old box in a corner. signature.asc Description: This is a digitally signed message part ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Loud PC speaker beep during reboot, sometimes
On Fri, 2022-09-23 at 08:13 -0700, stan via test wrote: > > I forgot to reply to this part of the message. I have been running > F37 > since it was rawhide, and have never heard this beep. But, I'm > running > a desktop, so that might make a difference. And a question. Are you > sure this is the PC speaker, and not something sending sound to the > sound device during startup? Does the sound come from the speakers or > does it come from the internals of the PC? The PC speaker is on the > MB, so should only be heard from inside the case. It isn't nearly so simple. The PC "squeeker" is ancient PC tech but almost every sound chip has an input to route it into the rest of the audio system and a mixer control to adjust it. Almost every PC motherboard also has a header to directly connect a speaker. This allows one to hear sounds created by the BIOS during POST, before the modern audio chip is initialized. Whether the motherboard or laptop actually connects the PC Speaker to the audio codec is almost entirely random. Whether anything is connected to the raw "squeeker" pins is random but tending more toward "not" every year that passes. Not allowing Linux to load the pcspeaker module will stop Linux from ever making a sound via that path but system level software running at higher privilege than the main OS can and often does use the speaker, over temp, fan failure, POST error, a happy beep at boot, all these things can still make sounds and there is a speaker attached or if the electrical connection is in place and the audio codec still has it enabled as a machine reboots, you can get beeps. About the only fix Linux could make is to ensure all audio channels are muted as the system goes into shutdown, reboot, sleep or suspend. That still won't stop a directly connected beeper though. signature.asc Description: This is a digitally signed message part ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads up - Anaconda 22.17 will enforce 'good' passwords
On Fri, 2015-01-30 at 13:13 -0700, Kevin Fenzi wrote: Because you cannot just say This is some decision, I know whatever I do will have good and bad tradeoffs, therefore, I will just not decide and expose all the possible choices to the user. Thats just not tenable. That is exactly what should happen. If you know that any decision will be wrong in some circumstances you try to leave it flexible to the extent possible by other limits such as developer time. The system requires a root password. Ok, the pure UNIX way would be to simply prompt for one. Because a typo here (especially since passwords don't echo) tradition calls for requiring it be entered twice as a basic sanity check. And that is all. This is also what the RedHat/Fedora installers actually did for many successful releases. If additional developer resources are available it is perfectly acceptable to add more sanity checking and inform / warn about unsafe passwords. Fedora has also used this policy, and again with success and no complaints. The second the developer takes the step of requiring their preferred password policy is when they have left The UNIX Way and adopted the attitude (endemic in every other computing culture) that the developers are superior to the users / admins. While perfectly normal everywhere else, that is a totally alien mindset for UNIX folk and is why the instantly negative reaction is occurring, a reaction that is probably more harsh than the actual case at hand would justify. I realize Fedora is no longer UNIX, doesn't even want to be a UNIX, but many users do still follow The UNIX Way and we haven't all been driven out yet. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Heads up - Anaconda 22.17 will enforce 'good' passwords
On Wed, 2015-01-28 at 19:33 -0500, Samuel Sieb wrote: On 01/28/2015 06:54 PM, Adam Williamson wrote: It was done as a follow-up / alternative to this Change proposal: https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no a lot of the reaction to that was along the lines of 'well, why not just make sure the root password is secure', and that got picked up by anaconda folks. You can follow the discussion in the devel@ and anaconda-devel-list archives. I just don't understand the reasoning here. Your understanding is no longer required. It is the new alien thinking that goes with the alien tech. Developers make the rules, users use the system as it is given unto them and are happy; because developers know things and stuff and users are idiots who must be protected from their idiocy. In times past a Linux installer was written with the notion that the person on the other end was another knowledgeable person, a peer, thus they were assumed to know what they were doing. A scratch install doesn't really need a strong password or whatever. Warn about unwise actions if developer time permits, otherwise let em get on with it. The same mindset was on exhibit last week with the discussion of forced formatting of partitions. The whole notion of any action not explicitly planned for and whitelisted is forbidden. Who cares if an admin has a good (if unusual) reason for wanting to do something, admins are obsolete now; now there are developers and users and Linux must shed the UNIX legacy that holds it back and become Chrome or Android or maybe it is OS X this week, who cares anymore. The pain threshold for reinstall isn't there yet I have probably made my last fresh Fedora install. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome desktop image for arm?
On Wed, 2014-07-23 at 14:35 -0400, Robert Moskowitz wrote: I don't know if Gnome arm images are being spun up or not, but, the issue with Gnome on ARM is with the graphics, not necessarily the memory. Allwinner A20 is suppose to have a fast GPU... OpenGL ES or full OpenGL? Almost all Arm chips limit themselves to ES since that is all Android requires. Yes it does make Arm kinda pointless for 'real computing' purposes, but the target market is phones, tablets and settop boxes. A real pity. Next problem is all video drivers on Arm (except, depending how you split hairs, the Pi) are blobs. If Fedora isn't officially admitting the otherwise pretty darned good Nvidia drivers exist I wouldn't hold my breath waiting for support for the craptastic stuff that passes for an embedded video driver. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Gnome 3.10: Network UI missing from new system status area
On Wed, 2013-10-09 at 11:46 +, Andre Robatino wrote: John Morris jmorris at beau.org writes: Screen space is valuable so removing an icon that is 'always' there and isn't typically displaying useful information is sensible enough. Possibly a dumb question, but doesn't space have to always be available for the icon, whether it's displayed always or just some of the time? I mean, if there was no available space to display a wired connection icon, and the connection goes down, it would be impossible to show the disconnected icon either. Nah, there are a lot of notifications icons that COULD appear, most don't unless they have something interesting to say. For example (not sure if the GNOMEs have defeatured it but it is there on 2 because it happened to me) if a drive is failing a SMART monitor tool will pop an icon into the system tray. Having it always there to say your drive is ok would not be useful. I have my power icon set to only appear if power is coming or going from the battery, same for the UPS's system tray icon. And there is always the icon that appears daily to let ya know you need to run update again. :) Really haven't though about what would happen if the system tray overflowed. Would it do like Windows and resort to a popup with more icons or like Android and slide? signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Gnome 3.10: Network UI missing from new system status area
On Thu, 2013-10-03 at 20:59 +0200, drago01 wrote: You should get an icon indicating failure just no success one. Which is even very unixy ;) Well GNU is Not Unix and these days Fedora isn't even following that star. How does Apple do it? Screen space is valuable so removing an icon that is 'always' there and isn't typically displaying useful information is sensible enough. But as the bug commenters noted, some people DO move between wired connections and such so an option to put it back really needs a bit of thought. And your idea that if anything goes wrong, loss of link, failure to acquire a lease, etc. it should put up a no-net icon is very good since these days no-network is the odd case, probably an error state and almost always something the user wants to know about. Better still of course if it has a tooltip with useful information. Any move to remove it with zero option should be a position that needs defending first, not something one person imposes from on high. If for no other reason than it is going to surprise people so some awareness building is probably a good idea. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: A different way of installing Fedora
On Wed, 2013-09-25 at 20:42 -0500, Kevin Martin wrote: Sounds like he is trying to do a Linux equivalent of Ghost...I see no reason for all of the negativity. If you have enough machines that are enough alike to be able to clone drives and install them on other machines and then make some very minor changes to get them running, I say go for it. You could even put a script on the primary drive that you then run on the cloned drives after install that asks you questions about hostname/ip/etc. and finishes the configuration for you. Should be an easy way to provision boxes it seems to me. Yup, I do the cloning thing as well to keep fifty some odd machines synced with a master. They currently run CentOS6 but the same tricks would work with Fedora There are issues though. Some of the auto stupidity must be neutered and little details fixed. The big one is to touch /etc/udev/rules.d/75-persistent-net-generator.rules and 75-cd-aliases-generator.rules if you still use optical media. If cloning you should be sure to clear out the key material in /etc/ssh to allow the clones to generate their own keys. Then do cp /dev/null /var/cache/cups/remote.cache Or you might have to wait a bit for printing to settle down. If you aren't moving the physical drive you have the choice of filesystem copy or image. If you do the copy through the filesystem make sure you aren't booting or mounting anything by uuid or you will lose. After that is details, clones shouldn't be updating on their own so I add steps to neuter the update icon, and so on. I have it down to a science with a USB stick that boots a very minimal Debian and by invoking a shell script it partitions a machine, rsyncs in a current system image and sets it up. It installs CentOS plus a little debian 'monitor' partition. When the master image updates the evening shutdown cron job fires off the monitor to rsync in the changes. Found it easier to update a system image if it isn't running at the time. Only time I have to touch a workstation is when hardware fails. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Moving away from reporting to RH bugzilla and adopting pure upstream reporting mantra.
On Mon, 2013-09-23 at 18:17 -0700, Bob Arendt wrote: The Fedora bugzilla, even if occasionally non-responsive, is *very* convenient. One can at least see if other users are experiencing the same issue. And other Fedora users cat at least leave bug comments that might aid other users (even if the comment points upstream). This is my experience as well. I no longer expect bugs to actually get closed but BZ is useful as a resource to read. The fix might even show up in a future package, even if the BZ# stays active or simply ages out. None of that changes the usefulness of searching through it. And after reading through this whole discussion there is really only one conclusion. Fedora is dysfunctional. Debugging is harder than writing and the developers have made Fedora as large and as complex as they can make it, meaning they can't possibly debug it anymore. Debating the details of infrastructure, who to report to, none of that is going to matter until the elephant in the room is dealt with. A little more care needs to go into deciding what is Fedora, if it can't be maintained it shouldn't be included. The ongoing talk to split Fedora into a well maintained core and layers above that is probably the right general direction. And while 'first' is a good goal, 'works' should perhaps be elevated to a co-equal status. Because if it doesn't work it isn't going to be 'fun.' Perhaps a rule that if packages you maintain have X or more bugs any packages pushed need to close a BZ#. And of the total bug count exceeds a limit nobody can upload a new package that isn't fixing a bug. Making new shiny is always more fun than maintaining, given a choice most people will go for fun and leave the fixing for 'later.' signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F20-rc3, gnome-shell logoff?
On Thu, 2013-09-19 at 11:02 +1000, Ankur Sinha wrote: If there's only one user, the log out option doesn't appear and you need to run gnome-session-quit in the alt f2 command dialog to log out. Ok, clever idea. Just wondering what kind of thought went into this though. I can't count the times I have been ordered to 'logout and back on' after a round of updates. Reboot? Every year Windows is getting a little better and we are getting a little more like it... too bad we are taking the bad ideas about as often as the good ones. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: What does one do about a package maintainer with an attitude problem?
On Mon, 2013-07-22 at 15:05 -0400, Fernando Cassia wrote: It seems to me like you don't know how to report bugs. Bug reports should include STEPS TO REPRODUCE, ALWAYS, it is not OPTIONAL. [voice=droll] So is is your stated position that intermittent or hard to reproduce bugs are 'someone else's problem' or are you asserting they they don't exist? Either it sounds kinda retarded, sir.[1] If the reporter knows how to reproduce a bug, of course they should report that. But an unexplainable failure is still a failure, and a report at least begins a conversation and provides an entry point for future reporters to search on and add to, eventually the hope being to collect enough clues to point to a solution. In a perfect world every bug report would include a complete breakdown of the problem. Or heck, if we are wishing we could just assume every user is a skilled developer who can code in every language, understand the OO.o, Firefox codebases AND troubleshoot ACPI bugs in the kernel and every bug report could be expected to include a patch as well. Or why not assume that every user is a registered Fedora dev and can just contribute a fixed package and we could eliminate bugzilla entirely. In reality even a bad bug report is better than silence, at least a bad report indicates that there is likely to be a real problem, even if it can't be solved yet. [1] Those not following recent U.S. news probably won't get the cultural reference. It's just a bad joke, not a flame. (A pot, kettle sorta gag.) signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: user list
On Tue, 2013-07-09 at 20:34 -0600, Stephen John Smoogen wrote: This email was not helpful nor being excellent to each other. It also shows a biased view that shows that the user didn't even try the version that shipped in at least alpha onward which does not use gestures but just a space or return. Next time try to actually be useful. Agreed. But then GNOME itself isn't too helpful and excellent hasn't been a word applicable to it for a couple of years now. Ya know we wouldn't get ticked off at this stuff if we didn't care about it, and it bothers us that stuff that was good and useful for years is now unusable rubbish and it was (intentionally?) made impractical to even keep the old stuff that worked. The whole bit with Cortez burning his ships might have worked out for him in the history books, but I bet his men didn't like it much at the time. Good grief, now I can't just ditch GNOME and move on, I'm going to gave to replace gdm as well. But no, not an earlier copy of Fedora. I installed the F19 release in a VM and banged away on the keyboard to no visible effect once it timed out and went to the tablet/phone style lock screen with the clock on it. Only the mouse would get a reaction from it. Just retried it to avoid doubling down on stupid. :) Fired up the VM and worked through more email until the lock screen appeared. Typed a character and the blanker did clear but my account name remained on the screen and that was as far as I could get without the mouse. Admitted that there are enough display/input bugs on F19 in a KVM (hosted on F18) that one could be biting me on this, but this doesn't look like a virtualization problem. Until the username is pointed to it doesn't light up and if it isn't lit it doesn't receive keyboard input. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: user list
Works fine here. What you're describing does not sound like the normal lock screen at all, to me. The lock screen has the user name and a password text entry box beneath it. Anything you type shows up in that box. Boot up, push the mouse away from the center of the screen and wait. Once the lock screen shows up try getting anywhere without the mouse. It certainly won't let me in. The blue lock screen did vanish but no keyboard activity would make my name vanish and a password prompt appear. Name remains in the Emo theme... dark grey text on a black screen. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On Wed, 2013-07-10 at 14:09 +0200, Karel Volný wrote: Dne středa, 10. července 2013 5:13:22 CEST, John Morris napsal(a): ... But then I remembered that if things have really went wrong you could boot with init=/usr/bin/bash. how do these advices help when the system is already so broken that it cannot reboot without help of sysrq or ctrl+alt+del combo? If it is a remote system you really should look into IPMI. If the system is really broken you really can't depend on ctrl-alt-del, SysRq or anything else to remaining working. Tell IPMI to toggle reset and hope the bootloader is still working, if it isn't repeat and boot rescue media from CD/USB, etc. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: user list
On Mon, 2013-07-08 at 10:58 -0400, Matthias Clasen wrote: See, GNOME _does_ listen :-) And yes, this is new in F19. They do listen. They don't always care. :) And for the record, HATE the new login screen. Impossible to login with only the keyboard and gestures are for tablets, not getting the login to appear on desktops. And of course it isn't configurable any more than you can turn it off once logged in. Nope, we have devolved from the over configurability of xscreensaver to the first fairly spartan and kinda broken gnome screen screensaver to this new crap that requires gestures to unlock and CANT BE DISABLED. (At least it can't be disabled through the official settings page.) The notion that I might not want a screensaver isn't even a valid thought in GNOMEland. Thankfully I only suffer GNOME once per Fedora release; to look at it, laugh at the stupid and then log out and switch desktops back to something sane. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd depends so heavily on a files it can not reboot
On Mon, 2013-07-08 at 18:02 +0200, Adam Pribyl wrote: OK, so the systemd people say, it is perfecly fine you can not reboot via ctrl-alt-del (while it was always possible with init) and give me the advice to enable sysrq for the purpose, and sysrq people say, it's not for users, we will not enable it, it is dangerous. Now I have a server, what should I do there? Use debian, right. Pondered this thread before saying anything. I'm still trying to decide if systemd is an overall improvement or a regression myself. But no, this case isn't a reason to use Debian. The default in Fedora is the only sane one because it is the safe choice. If you want sysrq and understand the implications you can enable it if, and only if, it makes sense in your situation. That is better than expecting every user installing a system they won't have absolute physical control over to know about and remember to disable it. And I was going to agree that systemd makes a system a lot less reliable in the face of serious problems since it needs a lot more files to be intact for it to get to runlevel S, especially in a situation where you don't have the physical presence to insert rescue media. But then I remembered that if things have really went wrong you could boot with init=/usr/bin/bash. And if you are in a remote colo situation it is probably prudent anyway to ensure rescue media is always in a non-default boot location so you can regain control. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18: when closing the lid, pm/sleep.d hooks not being run
On Thu, 2013-01-31 at 15:46 -0700, Michal Jaegermann wrote: On Thu, Jan 31, 2013 at 12:04:12PM -0600, Michael Cronenworth wrote: Michal Jaegermann wrote: You are not authorized to access bug #690713. Well, that does not help very much unless you happen to be authorized. I can see the bug just fine. Have you tried logging in? Good for you but I am logged in on bugzilla; right now. Maybe you are banned? Not on many other bugs but somehow on this one. M. It is a bug that has security implications or also applies to RHEL and was created by a paying customer who requested privacy. Nothing you can do about it. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18: when closing the lid, pm/sleep.d hooks not being run
On Thu, 2013-01-31 at 16:04 -0800, Adam Williamson wrote: On Thu, 2013-01-31 at 17:45 -0600, John Morris wrote: On Thu, 2013-01-31 at 15:46 -0700, Michal Jaegermann wrote: On Thu, Jan 31, 2013 at 12:04:12PM -0600, Michael Cronenworth wrote: Michal Jaegermann wrote: You are not authorized to access bug #690713. Well, that does not help very much unless you happen to be authorized. I can see the bug just fine. Have you tried logging in? Good for you but I am logged in on bugzilla; right now. Maybe you are banned? Not on many other bugs but somehow on this one. M. It is a bug that has security implications or also applies to RHEL and was created by a paying customer who requested privacy. Nothing you can do about it. This is a BGO bug, not an RH one. I can see it fine myself and can't see any visibility restrictions on it, so it's odd that Michael can't. I'm a 'normal' and I get the same message in a big red box when I try to look at that BZ number. It's locked. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Wed, 2012-11-07 at 07:51 +, Jóhann B. Guðmundsson wrote: We can still test this and installing Fedora, and arguably we should be doing that along other OS other than just Microsoft as well. We would just not have the Fedora release dependent upon the result from those tests... Really. So if it were known that Anaconda WOULD hose an existing Windows install you would be ok with releasing? Or if Anaconda simply puked and failed to install a working, booting Fedora in the presence of a Windows partition? That is what a release grade product does? And not just Windows, if Anaconda failed to do it's job and install a working Fedora without destroying any other OS install it is a serious problem. If the newly installed Fedora doesn't work it is a fail. If it causes damage beyond itself it is a disaster. Testing for and preventing such a PR disaster SHOULD be a release criteria. Failing to even test means that not only would a broken Fedora be released upon a unsuspecting world, there wouldn't even be a warning in the release notes to point to. Is it even possible to test every corner case out there in the complex world we live in? Probably not. Doesn't mean that making a respectable attempt is a bad idea. We have suffered since day one with Microsoft's refusal to admit other products exist and merrily destroy other boot loaders without so much as an I see something else in the MBR, should I overwrite it? prompt. We are supposed to be the White Hats and care about users and all that, lets live up to our own book of rules. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: How to interpret F18 Blocker criterion
On Wed, 2012-11-07 at 11:55 +0100, Chris Murphy wrote: I actually don't understand the RHEL angle on this missing piece either. What is the use case of installing RHEL along side Windows? Really, enterprise users do this? They share a single disk with one bootloader/manager taking over another? Seems risky to me. I'd think best practices would be, at best, separate OS's on separate drives, in the case of BIOS-MBR. For UEFI-GPT it's… different. One word: laptops. Few laptops can fit a second hard drive. And you quickly learn that in the real word you had better leave Windows installed so can get tech support, download new firmware, etc. So you resize it down to minimal and put your work OS on. And if you can't do it in a couple of tries then you will probably pick a distro that can pull it off. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: HEADS UP several very old sysconfig files are being deprecated
On Sat, 2012-10-27 at 01:24 +, Jóhann B. Guðmundsson wrote: I highly recommend against setting the hardware clock to localtime but because I know some of you guys are dual booting with windows and to lazy to fix the registry here's how you set the hardware clock to use localtime instead.. # timedatectl set-local-rtc 1 This all looks good, especially keeping this. It isn't just coexistence with Windows that makes it a good idea to put local time into the CMOS clock. If you want to wake up a machine in the morning it is a lot simpler to do with local time in the clock, otherwise you either have it waking up an hour early half the year or manually twiddle twice a year. Complete shutdown saves even more electricity than suspend and is less error prone on the typical desktop. Which adds up if you have a lot of desktops. I only have a few dozen but every dollar that isn't wasted helps. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 TC3 No Logout Option?: Wonko the Sane
On Wed, 2012-10-10 at 06:45 -0400, Kamil Paral wrote: When I click on the User Name in the right corner the options are Notifications, System Settings, Lock, and Power Off. Am I missing something? This is a new feature from the GNOME team (i.e. it's intended). They believe there are no use cases for logging out, if you have just a single user. Just read the thread up to current Am I the only one who thinks this conversation is insane? So now there will be logic to carefully look at whether there is more than one user account, then look to see if more than one session installed. Then the startx case may or may not (I'd bet not) be dealt with. And sometimes when you run updates you get a message about needing to log off and back on and sometimes you are told to reboot so I suppose that needs to also be accounted for.. or just always force reboots since apparently Windows is now our lodestar. All these bugs to deal with just to remove a menu option that wasn't hurting anyone. So I take it all other problems are now solved and we are free to waste time twisting knobs just for the heck of it now? People expect to be log in and then log out of machines, online services, pretty much everywhere. Where is the study showing this is confusing the always mythical hordes of AOLers who are supposed to be clammoring to welcome to the Penguin's icy embrace if we could only dumb it down just one notch below a Mac? Where? Anyone? Beuller? Maybe, just maybe, I want to log out when I'm not using the machine because I have good security habits. A modern machine has good enough power management that powering down completely is usually overkill, or have you guys just woke up from a coma and think it is still the 1990's? Any of you geniuses thought about that use case? Haven't security people been hammering that one into people's thick skulls since long before Linus was acrolling as and s across a screen and getting grandiose notions of world domination? Yes they have. And this change hoses all that effort. There is exactly one use case where eliminating the logout option almost makes sense, the case where a machine is set to automatically login an account on boot. But that still doesn't cover every possibility without a lot of extra effort. Now you kids get the heck off my lawn and go reread baggy pantsing in the Jargon File. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F18 TC3 No Logout Option?: Channeling Wonko the Sane
On Wed, 2012-10-10 at 15:03 -0400, Kamil Paral wrote: I have to say I agree with you. They create too much complexity (which will be broken by definition) to create a tiny simplification. This is an example of overkill. No. This BS has gone on long enough. Fedora is pretty much the only major distro shipping GNOME3 anyway so at some point handwaving about 'upstream' doesn't cut it. When does Fedora say that enough is enough? Besides, I haven't bothered to check but who wants to take bets that the genius who submitted this broken idea has @redhat.com on the end of their email address? This blame reflection game was old a year ago. Most of these guys are all in the same cubefarm but Fedora users aren't allowed to object because gnome is 'upstream' and RH doesn't listen, GNOME has an explicit policy to ignore end users so who the heck is responsible? So if the only choice for Fedora is to take GNOME from upstream 'as-is' or to not take it then so be it. Personally I think the only reaction left is a general call to simply remove GNOME as the default desktop environment in Fedora and thus to reject any changes from the GNOMEs that impact the new default. Can I get a second? signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: man files...
On Sat, 2012-05-05 at 17:52 -0700, Rob Healey wrote: Greetings: Could someone tell me which is more appropriate to do? place project manual files in: 1) usr/share/man/lang/man1/gramps.1.gz, or 2) /usr/local/share/man/man1/gramps.1 Which format is also better *.gz or *.1 ??? If you are creating a package it goes in /usr/share/man. If you are installing locally from a tarball you want it in /usr/local. RPM packages should NEVER (bold, underline and blink) touch /usr/local or /opt. Manually installed packages usually SHOULD use them, that is what they were designed for, And I think (but could be wrong) the .gz would be preferred since man deals with it just fine and it is smaller. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Inadequate sound device control
On Fri, 2012-04-20 at 17:46 +0200, Karel Volný wrote: Either way, file a bug report that's what I've done - would you dare to guess what is the reaction? Not our problem? They have a very good SEP field generator. Yes, there is usually some initial pain when major subsystems like audio or init get changed, but in the end, the result is so much better. ahem, PA got introduced in F8[1], this is nearly 5 years ago!(*) And some of us remember Pottering declaring years ago that Pulse was going to be subject to Brooks Law and was already planning it's replacement. Pulse is now getting close enough to working that more people leave it enabled than remove it so my money is on a new effort to rip and replace as soon as he gets done leaving system init and logging in a smoking heap of fail for others to finish.. most likely by ripping and replacing again. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17 Beta DVD install options
On Wed, 2012-04-18 at 12:22 -0400, David wrote: On 4/18/2012 11:11 AM, Dan Mashal wrote: My system is secure. Thanks for your concern. Fedora 14 is EOL since one month after Fedora 16. Fedora 15 will be EOL one month after Fedora 17. A long time with no security patches of any kind for any package for you. I know the type. 'I use Linux so I'm ten feet tall and bullet proof'. Maybe he is like me and has a machine that he can't upgrade. One of my machines has an HPT374 IDE RAID controller in it that hasn't worked for years. Last distro I cleanly loaded was RHEL4 (Whitebox4 actuallu) I managed to brutally hack the kernel in Fedora 10 with an old out of tree driver from Highpoint (GPL) to have something a little newer and did it again for F11 but a major kernel update along that line changed something I couldn't manage to fix. So that is where that machine stays until I finally toss the 4x200GB drives in it for a pair of larger ones connected to the onboard SATA plugs that should be supported. It is behind a NAT on a home network so I don't worry too much about it getting hacked. Firefox is almost certainly vulnerable but you rarely see active attacks in the wild against Linux browsers, especially if you don't hang out at dodgy sites. And if it happens, guess that will be the universe saying it is finally time to stop being a cheap bastard and buy some new drives. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17 Beta DVD install options
On Wed, 2012-04-18 at 18:13 +0100, Adam Williamson wrote: Not all hacks involve the attacker posting some kind of 'HAHA U HAZ BEEN HACKED' notice to let you know about it. Those are the _nice_ hackers. Well they usually DO something with a machine they have 0wn3ed. No spam spewing forth, no probes against other hosts, etc. And rpm -Va doesn't show anything nasty in the packages that would give an intruder an in. OpenWrt is running on the gateway so I see what sort of things are going through the NAT. And it is up to date. Is all that enough to be 100% sure? Nah. On the other hand if I were the sort of paranoid who spent a lot of time with those sort of thoughts I'd be running OpenBSD. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: No way to add a new app launcher from Gnome 3.x GUI?
On Wed, 2012-04-18 at 21:22 -0400, Matthias Clasen wrote: On Wed, 2012-04-18 at 15:04 -0300, Fernando Cassia wrote: I know this doesn´t solve my problem, but I´m outraged. In general, we expect an application to bring a suitable desktop file so it is usable after you installed it. That is even part of the packaging guidelines, last I checked. If the application you want a launcher for is something you created yourself, I don't think it is outrageous to expect you to write a desktop file after you already wrote the application... And nobody ever needed a launcher for a script or downloaded an app outside the package manager or did anything but be a nice little end user and let the GNOMEs take care of everything. Steve Jobs is smiling somewhere. I make .desktop files on a regular basis to fire off ssh sessions and such. Or did until I abandoned GNOME and found XFCE won't launch ssh via a .desktop link under some circumstances I haven't understood yet. Some of my existing desktop links work, others don't and I haven't nailed down the cause yet. Point being, creating app shortcuts is something a medium skill user should be expected to be able to figure out. Telling em to 'go fish' isn't really an answer that anyone should be willing to accept. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17 Beta DVD install options
On Thu, 2012-04-19 at 02:30 +0100, Adam Williamson wrote: And rpm -Va doesn't show anything nasty in the packages that would give an intruder an in. If someone's owned the machine, they can make rpm -Va say whatever they like. Which brings up a good point. I know that the only way to be sure is booting the machine from a known good[1] rescue media and then check with a copy of RPM running from there using the --root option to point at the suspect filesystem to ensure the system's rpm binary isn't trojaned or the kernel patched to show the original executables to rpm. And even then a REAL enemy would exploit a zero day buffer overflow in rpm via the infected rpm database. On the other hand, has there ever been a real case found in the wild of an infestation that was so good at covering its tracks? The security problems I saw in the past were the crudest script kiddies and I haven't even seen one of those attacks succeed since the 20th Century even on erratically updated machines. There aren't a lot of exploits against Linux to begin with, how many are going for deep penetration that aren't targeted hits by intelligence agencies? If the NSA wants to look at your or my machine they will and we will almost certainly never have a clue they were there. In short, just how theoretical an attack am I expending effort to repel? [1] And that IS the nub of the problem now isn't it; and the gateway to insanity. Do you trust the rescue media and/or the machine that downloaded and burned it? signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Move from /media to /run/media/$USER
On Fri, 2012-04-13 at 18:28 -0400, Al Dunsmuir wrote: O This behavior messes up a bunch of scripts I've written that assume the external USB drive MyBackupDrive will be hooked up as /media/MyBackupDrive no matter who's logged in when it's plugged in. Phooey. That ain't all that will get hosed. Wine has been confused about optical drives for awhile now and won't be getting better with this additional change. Deferring things until first logon only makes sense if there actually is a logon. That is an unwarranted design assumption - too many it must be a single user desktop assumptions/bias. I think this change is a wonderful option. Especially as the work on true multi-head gets closer to being useful. In that sort of scenario it will be great. But have to agree that it isn't the typical use case and should not drive the choice for the default behavior. If something like this is going to work for everyone there should be a way to pick on a per device or port basis how the device should be handled. So the system optical drive can be assigned to the user on seat 0 or be hard assigned to show up at a constant location. The USB ports on the hub with the second user's keyboard and mouse go to that user's desktop, etc. And then you could reserve a USB port or two for the system, to always give consistent names to the backup drives. Since the vast majority of systems are single user machines or servers the old UNIX ways should be the default since they work best for those typical usages. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Partition labels containing a slash in their names
On Fri, 2011-10-28 at 09:22 +0200, Joachim Backes wrote: Hi, I'm having 2 partions on /dev/sda (sda7 and sda8) labelled as /F15 and /F16. I wonder about the names in /dev/disk/by-label: lrwxrwxrwx 1 root root 10 Oct 27 20:12 \x2fF15 - ../../sda7 lrwxrwxrwx 1 root root 10 Oct 27 20:12 \x2fF16 - ../../sda8 I know that \x2f is equivalent to /, so why this mapping as special char? Because the / character isn't legal in a filename, it is reserved as the path separator. So it must be escaped or you could never access it. How did the filesystems get such a label in the first place? Any automated system that did it should have a bug filed against it since it is going to cause no end of confusion. If you did it, well don't do that anymore. :) signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: power saving?
On Fri, 2011-10-07 at 22:18 +0300, cornel panceac wrote: thank you , roy. i wonder if there's a way to tell the system to stay awake while different selected user space programs are running (like mplayer, eog, movie player, etc). Mplayer and probably most movie players can suppress the screen saver. So then the problem simplifies to can GNOME be made smart enough to leave the system powered up if the screen is on even if no keyboard or mouse activity is going on. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Well, I've tried GNOME 3 now...
On Wed, 2011-04-27 at 20:53 +0530, Rahul Sundaram wrote: It doesn't change the gist of the argument you are making but as a matter of historical record, Fedora didn't really chose GNOME actively even at the time of creation. Red Hat Linux chose GNOME over Enlightenment and FVWM back during the days when Red Hat Advanced Development Laboratories (RHAD) was created in 1998 inorder to fund GNOME development during the time when KDE was tied to a non-free Qt. Fedora Core 1 was basically Red Hat Linux 10 renamed. Much of choices are just inherited legacy. Fedora didn't even have its own logo until several releases later. Well it is time to choose because the old default choice is dead. Because GNOME3 bears almost no relation to GNOME2 so calling it an 'upgrade' needs a magic marker taken to the dictionary first. Since the argument that Fedora's mandate doesn't extend to maintaining a fork of GNOME2 is a valid one, that one is off the table. That means a new default environment must be picked. GNOME 1.X bore a strong kinship to GNOME 0.X, likewise for all the flaming that happened in the early GNOME 2.X period it was clearly the child of GNOME 1.X. GNOME 3.0 abandons the window manager, panel and all of the applets from GNOME 2.X, it abandons gconf, etc. It is a new thing in everything but name and a lot of the same people who have tossed GNOME under the bus in favor of their new tablet oriented environment. It is a totally new environment that builds on GTK+ and friends in exactly the same way that XFCE also builds on the same low level parts. So now Fedora must choose a default environment to build all it's internal tools around and base core assumptions upon. Picking GNOME3/GNOME Shell isn't accepting a default from upstream, it is a choice. An experimental one by any definition of the word and from the flame wars (and Ubuntu's decision to reject it) engendered by it an appeal to it's universal popularity certainly won't sell. It is a pity that the previous GNOME project has folded it's tent and forced this debate, but it is what it is. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Well, I've tried GNOME 3 now...
On Sat, 2011-04-23 at 07:50 -0700, Adam Williamson wrote: GNOME 2.0 came out in 2002, so we had that interface for nine years. It's not like no-one gave it a chance. Quite the contrary, people seem to like it and are confused when things that work are replaced with things that don't. Chris Adams upthread was on to something when he observed that GNOME3 isn't an upgrade over GNOME2, it is something new and different. Had it been honestly pitched that way everyone interested in GNOME could have known their favorite desktop project's maintainers had abandoned them over a year ago and made the decision to either step up and maintain it or put the effort into picking a new one. More importantly for the topic of a Fedora mailing list, had Fedora evaluated it as two events, the abandonment of the GNOME project and a new effort based on parts of the GTK and GNOME libs (kinda like XFCE) it is doubtful, as a new and immature effort at reinventing the desktop, it would currently be the default desktop for the Fedora project. As just another desktop spin there would be zero controversy over GNOME3. There would of course have been a major bikeshedding flameorama over which of the existing desktops would have been promoted to the new default. Viewed from an outsider's perspective the root of this problem seems to be too many of the dreamers behind GNOME3 are in RedHat and too deeply connected to the Fedora maintainers, also mostly walking the same cubefarm at RedHat. It would have been easier to tell some outside group they were getting kicked to an alternate spin and would have to compete to regain the default position purely on merit. Whether GNOME3 is a good idea for GNOME depends on whether there really is this mythical pool of new users they keep tossing their existing users over the side of the boat in a quest for. As someone who deals with public library users (currently on GNOME2) in a deeply rural area I can tell ya there aren't many totally virgin users left in the USA, so perhaps they are going for the third world. Perhaps they really are on the brink of bringing about 'the year of the Linux Desktop.' Either way, good for them because they are doing what they want to do and will either change the world or learn an important lesson. What isn't really debatable is that GNOME3 isn't a good fit for Fedora as very few Fedora users are going to be inexperienced new users. Few existing fedora users are looking for what GNOME3 is selling. Some might end up accepting it, but that isn't the same thing. Fedora should not be buying into a policy of chasing off existing or experienced users in the hope there are newbies waiting to jump in because that isn't Fedora's stated mission. The problem appears to be that there was never a debate so none of these questions were even asked until the release calendar had already imposed a commitment to ship GNOME3 as the default. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Multiple F15Beta bugs in under an hour
On Thu, 2011-04-21 at 09:51 -0400, Adam Jackson wrote: It's even easier than that. Click on the black title bar in the Display capplet and move it to the monitor you want it to appear on. Does that actually change the primary display or just move the bar? In other words, do other applications that want to pop things up on the primary display follow the bar when you drag it? Even if they aren't GNOME and or read gconf/dconf? signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Multiple F15Beta bugs in under an hour
Ok, downloaded the F15Beta live cd today. Booted it on a Thinkpad X200s docked with external display, keyboard and mouse + internal panel. Guess I'll run the bugs by roughly in the order discovered. Grub is the first one. The external keyboard didn't work. It does on F12 which is the primary OS on the machine. Lauching the file browser (nautilus?) and mousing over the available mount points got a crash from gvfs. Next bug is no debuginfo packages for key bits like glibc means no automatic bug report from abrt was possible. Guys, no debug packages means no good reports, which is the whole point of a beta, right? Cups is present and browsing is enabled but no printers show. Lots of printers are expected to show. Nothing interesting in the logs. My large display is to the left of the laptop. This is correctable via the GUI. Making it the primary display isn't, xrandr is required to set the primary display with 'xrandr --output HDMI2 --primary' If the user needs the terminal for something that basic, more baking needs doin'. Invoking the sound config locks if you click on a default sound. Quiet repeating grunts are audible until it finally crashes for good and again, abrt can't make a report. Not sure yet if that is a kernel problem, the eternal horror of pulseaudio or something new. When I get time I will poke around more and report. Please don't be a kernel bug! I have had to pass over F13 and F14 because of kernel bugs in undocking if I have to skip F15 for sound I'm boned. Pulseaudio I can remove. Launch firefox and display the About popup. Notice anything missing? Yup, the only way to be rid of it is to stop FF and kill off xulrunner-bin. Or perhaps xkill? Is this a window manager (mutter?) bug? And finally, good thing I read the mailing lists... otherwise I'd have never guessed holding ALT down was the only way to shutdown or reboot. What genius of user interface design thought that was a good idea? REALLY? Seriously, this is introducing a whole new idiom to user interfaces that people have zero expectation of. The choices presented in a menu should not vary based on buckybits. It violates decades of user expectations. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Multiple F15Beta bugs in under an hour
On Wed, 2011-04-20 at 20:39 -0500, John Watzke wrote: Are you saying that ABRT didn't download debuginfo packages? For a while now (not just F15) debuginfo isn't installed at install time. It just automatically gets downloaded when ABRT tries to generate the backtrace and it caches them in /var rather than installing them as full RPMs on the system. If ABRT didn't actually download the debugs that's actually a bug and you probably should report it. It tried to download and failed. The failure dialog suggested running 'debuginfo-install gvfs'. That also failed. Apparently yum can't find glibc-debuginfo and a couple others. Launch firefox and display the About popup. Notice anything missing? Yup, the only way to be rid of it is to stop FF and kill off xulrunner-bin. Or perhaps xkill? Is this a window manager (mutter?) bug? Not that I specifically agree with it but popup windows like the about window are dismissed with the Esc key rather than a close button. Gnome-shell has some minimalistic design decisions in it which will take some getting used to like the lack of a minimize button and the alt button press for a shutdown. That last one seems fine for desktops which I run 24x7 but not necessarily laptops which I tend to shutdown and pack away. Personally I consider GNOME3 a regression. After trying F15Alpha I went ahead and switched my desktop to XFCE since I have zero desire to relearn everything. But I wanted to test the main release in the interest of giving the best feedback. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Multiple F15Beta bugs in under an hour
On Wed, 2011-04-20 at 19:24 -0700, Rick Stevens wrote: I think the OP has a good bead on this. It is rather silly to change the paradigm (no close button on popups) and expect people to use the ESC key instead. Use the ALT button to shut down? What kind of lunacy is this? I can't believe it takes THAT much more code/CPU to implement a close button and leave the shutdown mechanism alone regardless of how minimalistic they want to be. Especially confusing since the window is still decorated with a thick bar at the top implying that SOMETHING should be there. Since they took away all the buttons and the title they should go ahead and suppress the bar. rant This sounds like change for change's sake and makes no sense whatsoever. The more I see of Gnome's silly decision making process, the less confidence I have in them. Surely Red Hat has some pull with these people. How about using a bit of it to quash these stupid plans? Red Hat can't realistically expect a RHEL release based on F15 and this sort of idiocy to fly with their customer base, do they? Seriously? /rant GNOME3 is more like an experimental university project 'to explore what we could do if we toss everything we know about existing user interfaces and start from scratch!' and it is now poised to ship as the default UI on one of the major Linux distros. I have a very bad feeling about this, suspect it will end badly. -- signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Multiple F15Beta bugs in under an hour
On Wed, 2011-04-20 at 20:59 -0700, Adam Williamson wrote: The expectation isn't that people should use Esc, it's that the dialog should have a Close button. Check the About dialog for any GNOME app. If the expectation is that 100% of applications will conform to Gnome UI standards, there is only one word that comes to mind. Delusion. Firefox being one of the better examples. It is a port, Moz doesn't really give a darned what Linux users need. Almost all of their users and most of the developers are on Windows. It will be almost as hard for Gnome to impose their UI notions on KDE app developers. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs. / Every OS sucks!
So now I lost the only kernel package where everything worked. And of course Fedora doesn't have it anymore. You can pick the original package or the current update. Triple crap! If anyone has a pointer to kernel-2.6.31.12-174.222.x86_64.rpm I'd really appreciate it! Google, rpmfind, etc. all come up blank as did manually poking around on the Fedora mirrors. You mean this one: http://koji.fedoraproject.org/koji/buildinfo?buildID=157491 Thanks! Was really hoping those old updates were still somewhere out there. Really hate self inflicted wounds, nice to know it wasn't terminal. Especially since someone else just joined my bug with the bad news that F13 does have the same problem. Looks like I'm going to be stuck with F12 and that one working kernel for a while yet. Not sure what the plan is when the next major security problem pops after F12 goes unsupported but there is still a couple of months until that problem becomes acute. I hoped venting helped you, but this is not the way to move things forward. I'd suggest more help testing, good bug reports.. Dunno, reported this one in March and it is still in NEW state. Reported #563417 in Feb and it is also in the NEW state. Thankfully I could work around it by binding a script to CTRL-F7 to fire blindly that looks at the state of the dock and manually launches some xrandr commands to force things into shape. The panel picks up on dynamic changes in screen geometry just fine so force it down to 1024x768, wait a second or two for it to reappear then resize to the current attached primary panel's size. Not ready for Grandma but that one doesn't bother me as much as some of the things I was ranting about because it is a bug in something that is clearly a new feature. The agility of xrandr has been amazing to watch over the last few years. Hopefully all the other bits like the panel will catch up in another rev or two. And maybe the system will even get smart enough to remember where you put the displays and restore that when the same external monitor is reattached. Closer to my original rant is the snarky observation that the Gnomes probably won't ever get around to fixing such a minor problem because they are too busy ripping and replacing the whole desktop with an entirely new set of bugs to care about fixing the few bugs in the current code that is set to get tossed out anyway. The problem I was ranting about is more about a growing fear of upgrading, or heck, even taking patches for fear the bug being fixed (which most of the time isn't actually biting ya) or feature improvement (which you probably don't need) will also break your system. What if a critical mass of users decide that once they manage to get their system working that the only safe course of action is to then disable all updates. If a bug does start biting hard check to see if that one package can be updated without dragging in lot of deps, otherwise stay put until hardware replacement time. Where does that leave things? If normal users stop taking even the updates how does wide scale testing happen? I have 'beater' machines, I have QEMU, etc. You probably have similar. Most people don't. This isn't just a thought experiment; Microsoft already faced the same problem and got around it by making Windows Update (all but) mandatory. How many people are still on XP? How many IE6 hits are in your server logs? signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs. / Every OS sucks!
On Thu, 2010-09-09 at 00:14 -0500, Bruno Wolff III wrote: On Wed, Sep 08, 2010 at 23:18:00 -0500, John Morris jmor...@beau.org wrote: And of course Network-Manager isn't optional anymore. Oh no, you can't You can still run the network service. You use chkconfig to turn it on. If you don't need wireless, turning off NetworkManager doesn't seem to be a problem, but it's also possible to run both at the same time. No it isn't. If NM isn't managing a connection to the Internet then Firefox (fixable), Evolution, Empathy and almost certainly other apps go into offline mode. You can still run a server without NetworkManager but a desktop install now requires that it be installed and managing your connection. Been there, tried that and have the t-shirt. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: firefox always starts offline
On Thu, 2010-09-02 at 08:50 +0300, cornel panceac wrote: something strange happens on one of my test pcs running f14 (updated). firefox always starts in offline mode. i uncheck work offline and eevrythings fine until i close and start again firefox, when it's in offline mode again. what could be the problem? NetworkManager is stopped because it's not working. If NetworkManager stops your network stops, period. Firefox, Evolution and Empathy for sure depend on it and eventually everything will. You can frob an undocumented option on Firefox's about:config screen but no known fix exists for the others. Solution: Troubleshoot your NetworkManager problem. It isn't optional anymore. Whether that is wise is a question best left to the philosophers. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, 2010-09-02 at 14:17 +0200, Dennis J. wrote: What I would like to see is a distinction between regressions and other bugs. There are a least two reasons why this might be worthwhile: 1. Regressions break functionality that has been known to work previously and the users already rely on. If new stuff gets added and has bugs that is not as serious because users are not yet relying on this to work. 2. Regressions can be easier to fix because you have a known to work case you can use as a comparison. If bugs could be flagged as regression then developers you potentially look at these first right after the regressions occurred and probably identify the reason for the regression right away. I'd like to suggest another reason regressions should get higher priority. Regressions hit people who already have Fedora installed and running and puts us in a bad place. Every install is less than a year away from being unsupported and a serious regression leaves us unable to stay on the upgrade treadmill. In my case I reported #573135 back in March and stopped taking kernel updates. In another month or so I'll boot a live USB stick of F14 and see if the bug was fixed and just didn't get closed. Then it is either suck it up and run without security fixes or jump distros. That is the difference, a bug in a bad place might stop a new user from migrating to Fedora while a regression combines with the short support cucle to force an existing user to migrate away if it exists across two releases. There really needs to be a change of attitude from Ooh! Shiny! Ship it! to not shipping new until it at least does everything the old did and reverting when serious bugs appear and can't be quickly patched. Yes I realize I'm suggesting something that will result in new stuff taking longer to arrive. At some point we really need to begin a shift away from furious development of new features into a more quality driven focus. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
