Re: proposal: drop optical media from release criteria
On 9/20/18 1:35 PM, Matthew Miller wrote: > On Thu, Sep 20, 2018 at 04:23:03PM -0400, pmkel...@frontier.com wrote: >>>> There are still some systems out there that won't boot off native >>>> USB media and need CD/DVD emulation over USB to work. I don't think >>>> the time is yet ripe to jettison optical media. Soon, but not just yet. >>> How many such systems? Is it worth the cost to support them? Are users of >>> those systems in the targets for our release-blocking deliverables? >> We buy used, manufacturer refurbished PCs for the most part to keep >> costs down. They are generally 5 years old when purchased and they >> get used for another 5 or more years. They run Fedora and the >> applications we use just fine. So now it sounds like your telling me >> I need to buy newer PCs. What age limit do you propose for PCs >> before Fedora will no longer support them? > > So, again, I'm looking at the target audiences for our release-blocking > deliverables. 5 years seems like a perfectly reasonable age limit for the > audiences for those. Maybe even 3 years. Do you have 5 year old computers > that don't boot from USB? > > Now, it's totally within the mission of Fedora > <https://docs.fedoraproject.org/en-US/project/> to enable people who care > about targetting older hardware to develop, produce, and support solutions > for that. That would be super, super awesome. If you're interested in > finding other people with similar needs and want to build that, I'm totally > in favor of doing that as part of Fedora, with Fedora resources, using > Fedora infrastructure. > > >> Oh I forgot to add in my prior replies on this subject that we used >> DVDs for long term backups too. > > This isn't about whether DVD writing works, though. In fact, it's not > necessarily about dropping support for DVD installation either -- it's > *likely* that it will just keep working, and even if we ship a release which > you discover after the fact doesn't work for you, there's nothing blocking > producing a fix. We just wouldn't slip the release for it. Ok, so ISO images would still be produced and could be burned to OM for installation. There just isn't any guarantee (at release) that the OM would actually boot and one could squawk it if it didn't and not be poo-poo'd about it. I might be able to survive that, assuming that the fixes for the unbootability (is that a word?) were timely. I'm sorry for opening such a storm of messages here. I'm just a bit sensitive to this as I'm the one that generally gets poked with the sharp, pointy stick when the defecation hits the impeller around here. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- - Never eat anything larger than your head - -- ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: proposal: drop optical media from release criteria
On 9/20/18 12:59 PM, Samuel Sieb wrote: > On 9/20/18 12:30 PM, Rick Stevens wrote: >> On 9/20/18 12:26 PM, M. Edward (Ed) Borasky wrote: >>> +1 to dropping the optical media criterion for Fedora, but I still rip >>> CDs and DVDs ;-) >> >> There are still some systems out there that won't boot off native >> USB media and need CD/DVD emulation over USB to work. I don't think >> the time is yet ripe to jettison optical media. Soon, but not just yet. > > This isn't dropping the ability to use optical media. It's just a > suggestion to drop the release criteria that a physical optical media > not booting will not block the release. So there is a potential that the software will be released, but not on optical media. That may cause myself and others like me some grief. > What system doesn't boot off USB now? What do you mean by DVD emulation > over USB? That still sounds like not physical optical media. I manage several data centers with some hundreds of servers. Granted, the vast majority of them run CentOS, but some do run Fedora. And, as Fedora goes, eventually so goes CentOS. Some of these beasties are of, well, "older" vintage and are unable to boot USB media natively. They can boot some USB-based and most IDE-based CD/DVD drives. I'd love to replace them with newer systems but am unable to unless they actually die an ugly and permanent death. I have to justify the cost and replacing them "just because they're old" doesn't fly with our cost accountants. I'm stuck with them. Now, perhaps if I say, "I can't install newer software on them because they can't boot that media," perhaps they'd relax the purse strings. Not bloody likely, but perhaps. Changes such as this to the infrastructure can have repercussions to people like myself that may not be apparent to those not in my position. Optical media is still necessary for me at this time. I'm just putting in my $.02, that's all. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- - What's small, yellow and very, VERY dangerous? The root canary! - -- ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: proposal: drop optical media from release criteria
On 9/20/18 12:26 PM, M. Edward (Ed) Borasky wrote: > +1 to dropping the optical media criterion for Fedora, but I still rip > CDs and DVDs ;-) There are still some systems out there that won't boot off native USB media and need CD/DVD emulation over USB to work. I don't think the time is yet ripe to jettison optical media. Soon, but not just yet. > On Thu, Sep 20, 2018 at 11:54 AM, Chris Murphy > wrote: >> On Thu, Sep 20, 2018 at 11:49 AM, Matthew Miller >> wrote: >>> Justification: >>> http://newsthump.com/2018/05/21/man-decides-to-keep-box-of-cables-hes-has-since-2002-for-another-year/ >> >> >> +1 to dropping the optical media >> criterion---------- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- - Never test for an error condition you don't know how to handle. - -- ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: installing / removing software
On 07/17/2018 02:53 PM, Adam Williamson wrote: > On Tue, 2018-07-17 at 14:48 -0700, Adam Williamson wrote: >> I instinctively like the non-split form here because, to me, it >> emphasizes more clearly that "appropriately" applies to all three >> actions. > > To be clearer here, consider these options: > > "...to appropriately install, remove and update..." > "...to install, remove and update appropriately..." > "...appropriately to install, remove and update..." > > To me, it's at least possible that someone might read the first as if > the "appropriately" applies only to the action "install", and the > second as if the "appropriately" applies only to the action "update". > The third, however, can't really be understood in any way *other* than > with "appropriately" applying to all three actions. I can still see the third as being interpreted as applying to install only. How about: "...to appropriately perform the action required (install, remove or update)..." Language and statistics are akin to a bikini...what they reveal is suggestive, and what they conceal is vital! Just my $0.02 (in US dollars) -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- - What's small, yellow and very, VERY dangerous? The root canary! - -- ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/5KPTAFYVRFI6PQCEDNCF3C7TYCM3YQWV/
Re: Release criteria proposal: installing / removing software
On 06/13/2018 09:56 AM, Adam Williamson wrote: > On Tue, 2018-06-12 at 21:51 -0400, Matthew Miller wrote: >> On Tue, Jun 12, 2018 at 11:35:21AM -0700, Adam Williamson wrote: >>> "The installed system must be able to install, remove, and install >>> appropriate updates for software with the default console tool for the >>> relevant software type (e.g. default console package manager). This >>> includes downloading of packages to be installed/updated." >> >> +1 in theory. The wording is a bit awkward, though -- it sounds like >> "updates" are things we must be able to install, remove, and install >> again. Why not just: >> >> "The installed system must be able to install, remove, and update >> software with the default console tool for the relevant software type >> (e.g. default console package manager). This includes downloading of >> packages to be installed/updated." > > We already have a thread about exactly this wording problem. :P The > reason I didn't go for that wording is that it loses the 'appropriate' > concept, which is important and was specifically included. It appears > that people are having trouble parsing the intended sense of the > wording I chose - there are three actions, "install", "remove" and > "install appropriate updates for", all of which affect "software" - so > I'm trying to think of another way to put it. How about: "The installed system must be able to install and remove packages, and apply updates to installed packages using the default console tool for the software involved. It must also support downloading packages for later manual or automated installation." Or did I miss the intent? -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- - Let us think the unthinkable. Let us do the undoable. Let us - - prepare to grapple with the ineffable itself, and see if we may - - not eff it up after all. - - -- Douglas Adams - -- ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/DBJNHMZUUSKMPJZN3FZETKYIVZXTP2W5/
Re: Missing DRPMs for F26
On 08/25/2017 11:50 AM, Kevin Fenzi wrote: > On 08/25/2017 09:41 AM, Rick Stevens wrote: >> Hi, guys. >> >> I don't know if this is the correct forum for this, but over on the >> users' list people have been talking about the fact there haven't been >> any delta RPMs released for F26 updates. For those of us who don't have >> download limits, this isn't a problem. However, many people do have >> these limits and this could present a big issue for them. >> >> As I said, I don't know if this is the correct place to mention this >> or if it should be brought up on the infrastructure list. > > As noted on infrastructure list: > > Short answer: Yes. We know they are currently not working for f26. > > Long answer: With the addition of alternative arches in f26, we cannot > do drpms the same way as we used to, because some of the packages are > under fedora-secondary and some are under fedora. We need a fix for > https://github.com/fedora-infra/bodhi/issues/1685 in order to get this > working again. > > Hopefully we will have a patch soon and they will be re-enabled. Thanks for the response and the posting on the users' list. Much appreciated! -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- - NEWS FLASH! Intelligence of mankind decreasing! Details at... - - uh, when, uh, the little hand is, uh, on the... Aw, NUTS! - -- ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Missing DRPMs for F26
Hi, guys. I don't know if this is the correct forum for this, but over on the users' list people have been talking about the fact there haven't been any delta RPMs released for F26 updates. For those of us who don't have download limits, this isn't a problem. However, many people do have these limits and this could present a big issue for them. As I said, I don't know if this is the correct place to mention this or if it should be brought up on the infrastructure list. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- - We have enough youth, how about a fountain of SMART? - -- ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: Last released kernel
On 03/01/2017 11:18 AM, Chris Murphy wrote: > On Wed, Mar 1, 2017 at 2:07 AM, Russel Winder <rus...@winder.org.uk> wrote: >> I appreciate that Rawhide always has the latest kernel snapshot as the >> one and only kernel and that it is up to users to manage their own >> kernels. However I wonder if there should be a simple, standard way of >> being able to install the last released kernel, perhaps a package last- >> release-kernel or something. >> >> The problem for me is that the release kernel only ever seems to be in >> Rawhide for one day, and if I miss updating on that day, I have missed >> capturing that kernel – it just happened with 4.10 so I am stuck with >> an rc8 rather than the release. (And 4.11 won't actually work for a few >> rcs yet, same for every new kernel.) > > In dnf.conf add an exclude for the kernel, and then just manually > install them from koji. So you download kernel kernel-core and > kernel-modules RPMs from koji, then you can do 'dnf install *rpm' > while in the same directory that has the RPMs and it'll install them. > > What you want to do isn't really possible right now I think. Fedora 24 > and 25 are still on 4.9 kernels, they haven't rebased to 4.10. So > there is no repo with 4.10 in it, and in fact 4.10.1 has not been > built yet. Fedora 25 is indeed on the 4.9 kernels (latest release is 4.9.12-200). -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- - Is that a buffer overflow or are you just happy to see me? - -- ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: gnome-software no notifications, but pending updates
On 12/29/2016 07:20 AM, Chris Murphy wrote: > > > On Thu, Dec 29, 2016 at 3:48 AM, Kalev Lember <kalevlem...@gmail.com > <mailto:kalevlem...@gmail.com>> wrote: > > On 12/23/2016 11:52 PM, Chris Murphy wrote: > > In gnome-shell if I go to restart (upper right corner, power button > > icon) I have an 'install pending software updates' now for two days, > > but there's no other notification that there are pending software > > updates. > > > > Is this change in behavior expected? Seems like a bug. Maybe I'll > > leave it alone for a couple more days and see if it continues to > > accumulate updates without any notification. > > gnome-software notifies only once per week as per design (or more often > when there are pending security updates available), but at the same time > it does prepare the offline update as soon as it finds new updates so > it's possible to install the updates manually more often if you want to, > either through the gnome-shell shutdown dialog or from gnome-software > itself. > > I don't think there's been a behaviour change here, unless there's a bug > somewhere of course. > > > A side effect of this, is multiple package versions are being downloaded > but not installed; only the latest version is installed. a.) this is > consuming bandwidth for no purpose and b.) PackageKit only removes the > downloaded packages that it installs, anything not installed remains > behind to take up space, never being deleted. Yes, item b) is bad. It's caused a lot of comment over on the users list. IMHO, packagekit should replace any older versions of packages it downloads so that only the latest version of a package is held in the cache. There's no logical reason to hold obsoleted packages unless you have a desire to be a pack rat (or should that be "packagekit rat"?) Alternately, make holding the old packages optional (with "purge" being the default) or doing something like dnf's "installonly_limit" thing. Not everyone has huge disks to hold masses of outdated content. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- - Never put off 'til tommorrow what you can forget altogether! - -- ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: QA group joining process: new members cannot subscribe to list until approved
On 08/05/2016 12:48 PM, Adam Williamson wrote: > Hi folks! In an IRC discussion with a new member this morning, we > became aware of an issue (possibly some folks knew about this already, > but I didn't!) in the joining process. This is mostly of interest to qa > group moderators/sponsors, but I figured it can't hurt to make everyone > aware. > > Recently, the Powers That Be have made it so you can't subscribe to > Fedora mailing lists until you're a member of the FAS 'cla' group > (which you become a member of by signing the contributor agreement) > *and* one other group. This requirement is intended to combat spam > coming from bots which just create new accounts, sign the CA, then > start subscribing to lists and sending out spam - that whole process > can be fully automated, and has apparently been a real problem. So the > intent is to make sure only people who've been made a member of a > 'real' FAS group by some kind of human, non-automatable process can > join the lists. > > When we wrote https://fedoraproject.org/wiki/QA/Join , this wasn't the > case, and the idea was more or less that people should apply to the > group and *at the same time* join the mailing list and send a self- > introduction mail; the self-intro would show that they were a genuine > applicant, and moderators could approve their membership after seeing > the self-introduction mail. Since then we made it a bit more ambiguous > and made it so the self-introduction mail isn't required, but I still > tend to look for a self-intro mail before approving new members. > > Obviously, with the new rules, many prospective members won't actually > be able to join the list and send a self-intro at all until we approve > their membership - they could only do so if they were already a member > of some other Fedora group. > > So, I'm proposing we make a slightly tweaked process explicit. My > suggestion is that it should work like this: > > 1. Prospective member sends group membership application > 2. A sponsor contacts the prospective member - usually by email, but > IRC is fine if both the prospective member and the sponsor happen to be > there - to confirm they're a real person, really interested in QA, and > they've read the Join page > 3. If there's a positive response, the sponsor approves the membership > 4. The member can now join the list and send a self-intro mail > (encouraged but not required, as now) > > When contacting prospective members by email, sponsors should copy the > mail to qa-spons...@fedoraproject.org , so other sponsors are aware > that the prospective members have been contacted and we don't get > duplicate contacts. If contacting *multiple* prospective members at > once with a single mail, sponsors should send the mail To: qa-sponsors@ > fedoraproject.org and *BCC* the prospective members, so their email > addresses aren't disclosed to each other. > > Does this all sound OK? If so, I can tweak the Join page a bit to > reflect this process, and maybe throw together a sponsor SOP for > sponsors. Thanks everyone! Uh, wouldn't the addition of a "captcha" on the signup page make joining up without requiring additional group memberships easier and more bot-proof? That would also prevent the sponsors having to deal with a slew of botted initial contacts. Just a thought. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- - Politicians are the opposite of pickpockets because you never see - -them take their hand out of your pocket.- - -- Larry Fine - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Fedora rawhide compose report: 20160527.n.1 changes
On 05/27/2016 11:39 AM, Fedora Rawhide Report wrote: See a typo: Package: kf5-calendarsupport-16.04.1-2.fc25 Summary: KDE PIM library for calendar and even handling RPMs:kf5-calendarsupport kf5-calendarsupport-devel Size:1000536 bytes I think you mean "event handling", although "even handling" of a calendar is a good thing, too! :-) ------ - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- - A day for firm decisions!!! Well, then again, maybe not!- -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Latest state of Rawhide
On 04/29/2016 06:44 AM, Russel Winder wrote: On Fri, 2016-04-29 at 08:20 -0400, Kamil Paral wrote: I am guessing it is well known that the gdm process runs but does not get the login screen started in the current Rawhide? It could be this: https://bugzilla.redhat.com/show_bug.cgi?id=1331668 -- I suspect you are right, I rebooted with the selinux=0 boot option and GDM does what it should. Using enforcing=0 does not allow DGM to do its job unlike what the bug report post claims, so maybe there are differences. We shall see… It's interesting you mention that. I've seen selinux behave differently between disabled state and permissive for a long, LONG time. As I understand it, permissive should allow all operations but give warnings while disabled means, well, disabled. However, I've seen permissive mode _block_ some operations and not issue any warnings about those blocked operations. I can't give details about what has been blocked in the past. I've lost track of the records. I do recall a lot of it had to do with networking operations. This issue seems somehow related. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- - A squeegee, by any other name, wouldn't sound as funny. - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: [Test-Announce] Fedora 23 Final Release Candidate 9 (RC9) Available Now!
On 10/29/2015 04:49 PM, Adam Williamson wrote: On Thu, 2015-10-29 at 12:21 -0700, Adam Williamson wrote: As a heads-up, it's possible we'll be doing an RC10 to try and fix the anaconda help issue. Work is ongoing on that. So yep, this is happening: RC10 with a reverted yelp (to fix the anaconda help issue) is spinning now. The idea is that we get RC9 and RC10 both smoke tested, and go/no-go can choose to ship RC9 or RC10, fudge the release-notes issue and ship RC6, or do something completely different (like slipping again). RC10 should land in ~3 hours (approximately), Dennis says he's tried to set it up so it will just appear in stage/ when it's complete without him having to do anything, so we'll keep an eye out. As with RC9, the goal should be to do basic smoke tests - burn it to media (optical and USB) and make sure everything works as expected. We should also check Anaconda help works and also GNOME application help still works (I've done this with a scratch image, but we should re-test with the real thing when it's done). Sigh, I love crunch week... Wait, you've actually had weeks that DON'T have a crunch factor? What are they like? Sounds nice! -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- - Dyslexics of the world: UNTIE! - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: The most recent kernel: Plague of Fives, and fatally inefficient networking
On 09/28/2015 11:03 AM, Temlakos wrote: On 09/28/2015 01:38 PM, Dan Mossor wrote: On 09/24/2015 02:27 PM, Temlakos wrote: Everyone: 1. The kernel, once again, is prone to an annoying flaw: it produces a Plague of Fives. Any time a text box opens up, a string of repeated digits 5 appears. The only way to shut it off is to type "5" again. /No/, kernel group! Do /not/ tell me I have a problem with a sticking 5 key. If that were the problem, then pressing Shift would change "555..." to 55%%..." It doesn't. More to the point, the Plague of Fives tended to go away with the next iteration of the kernel. Temlakos Huh, and here I thought my "refurbished" Logitech Wave wireless keyboard wasn't fully refurbished. I had a weird problem with the 5 key a while ago - the only way to stop it was to hit "5" on the number row. No other key would stop it, and shift didn't change it. But it's gone now. I think. The Plague of Fives came back with the latest kernel push. Which is one reason I rebooted to the last known good kernel. That stopped the Plague of Fives, and also resolved an issue with some very slow file transfer across my private network. Again, please stop using "last known good kernel" and such indistinct descriptions and give us the kernel version numbers involved. We have no way to determine what you have installed and what you haven't or what order they're listed in in your grub configs. ------ - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 226437340 Yahoo: origrps2 - -- -I don't suffer from insanity...I enjoy every minute of it! - -- -- 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 02/05/2015 01:27 PM, Scott Robbins wrote: On Thu, Feb 05, 2015 at 12:53:45PM -0700, Chris Murphy wrote: On Thu, Feb 5, 2015 at 10:36 AM, Brian C. Lane b...@redhat.com wrote: Next to impossible? Really? I've find it easy to come up with passwords that work. You think this is easy. Other's don't. It's a condescending, pointless, and unwinnable argument, and it needs to stop. You might also look at the CentOS list, which has a high percentage of people who, y'know, actually use this stuff to make a living. You'll find that it's overwhelmingly against this. I don't find any of the arguments against the change to be compelling. Well, I don't find any of the arguments for a change, that will probably violate POLA (principle of least astonishment) at all compelling. You're making the change, it is up to you to justify. This reminds me of the time when they wanted packagekit to allow any user to upgrade any package--even now, any user can upgrade any installed, signed package--and they were going to go through with it till it made the front page of slashdot. I have to agree with Chris. I have absolutely no issue with the installer _warning_ me that the password I chose is (in the INSTALLER's opinion) weak. The installer should ABSOLUTELY NOT force me to use some arbitrarily obscure password to satisfy its criteria. I have very good reasons for using the passwords I choose. One example: We often have accounts that log in to collect data (e.g. nagios or rancid) for monitoring purposes or config change deltas. If the installer suddenly changes the password requirements, then the existing systems all have to be changed to match, and the monitoring software also has to be reconfigured. That is truly invasive. I manage well over 400 systems spread around in three data centers and I have to change everything because some self-righteous coder thinks my passwords are inadequate? All the installer should do is install a functional system. If something comes up that may be odd, then fine, warn the user about it but do what the user tells you to do. Leave it up to the system admins to harden the system if they need to. We should be encouraging them to choose stronger passwords and we should remember that we're not the only people running Fedora. Yes, but most running Fedora aren't totally inexperienced. Nor for that matter, are people running Mint or Ubuntu--most have at least some knowledge of computers, otherwise, they run Windows or OSX. soap Encouraging is one hell of a lot different than beating them over the head and not letting them configure the system THE WAY THEY WANT IT CONFIGURED! /soap -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- -You think that's tough? Try herding cats!- -- -- 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 01/30/2015 12:21 PM, Adam Williamson wrote: On Fri, 2015-01-30 at 12:59 -0700, Chris Murphy wrote: What's the actual, real world, non-imaginary impetus behind the change? It's exactly what all the list posts I pointed you to say it is. I don't know how to stop the conspiracy virus which causes people to leap to the conclusion that there's some shadowy secret motive behind every change they don't like, but there *isn't*. PJP posted about his change proposal to anaconda-devel . bcl said 'that doesn't sound like a good idea, but we take your point about possible brute force attacks against services enabled ootb, and an easy way to mitigate that is to require strong passwords'. anaconda already *has* a password strength checker, so it probably took him all of five minutes to make it mandatory instead of optional. Then he dropped a mail here as a ^ courtesy heads-up. that's the entirety of what happened. That's what's setting people off--making it mandatory unilaterally. I have no issue with the system nattering at me that the password is (in the installer's opinion) inadequate, but do NOT stop me from using it. I probably have a damned good reason to use it. After all, I put in my weak password twice (and note the second time was AFTER the system bitched about its perceived weakness). I obviously want it set to what I entered. If I wanted to be led by the nose, restricted in what I can do and nannied constantly, I'd use Windows or a freaking Mac. Sheesh! -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - BASIC is the Computer Science version of `Scientific Creationism' - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
openssh linked against old openssl
I just did a fedup of a Fedora 20 machine to Fedora 21. It wouldn't let me log in via the GUI (XFCE). Looking around, it appears a number of items are linked against an older version of openssl. For example, sshd, ssh-agent, yum and libvirtd all wanted libssl.so.7 (although after a reboot, libvirtd was happy). It appears that fedup installed openssl-1.0.1j-1.fc21.x86_64 (which provides libssl.so.10) and purges the older version that provided libssl.so.7. According to yum, the openssh I have installed (6.6.1p1-9.fc21) is the current one but it still has this need for the older openssl: [root@golem4 ~]# ldd /usr/sbin/sshd | grep ssl libssl.so.7 = /lib64/libssl.so.7 (0x7ffbcc44d000) This breaks a LOT of stuff. I ended up making symlinks in /usr/lib64 to satisfy these issues: # cd /usr/lib64 # ln -s libssl.so.1.0.1j libssl.so.7 # ln -s libcrypto.so.1.0.1j libcrypto.so.7 I can now run my system, but I'm not comfortable with doing this hack. It looks like something got missed. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - Real Time, adj.: Here and now, as opposed to fake time, which only - -occurs there and then - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup failure from F19-F20
On 04/25/2014 04:30 PM, Rick Stevens issued this missive: On 04/25/2014 02:54 PM, Adam Williamson issued this missive: On Fri, 2014-04-25 at 11:49 -0700, Samuel Sieb wrote: On 04/25/2014 11:42 AM, Rick Stevens wrote: Yup, I have yum-plugin-local installed. I'll kill it off and remove the /var/lib/yum/plugins/local RPMs. Now, assuming I clean all that cruft up (getting rid of the plugin-local stuff, getting rid of the RPMs), how do I proceed with the upgrade? It seems like fedup is stuck looking for that sqllite file which doesn't exist. Is there a cache somewhere I need to purge? If you followed the previous steps I mentioned, all the caches should be cleaned, but I strongly suspect your problem was caused by that plugin. So just try fedup again. ^^^ this, but if it turns out you do need to clean up after the earlier failed fedup run for some reason, try 'fedup --clean'. I did that along with a yum clean all just for good measure. I got pulled off onto other things today, but I'm doing a fedup --disablerepo=google-chrome --network 20 right now. We'll see how it goes. Thanks again for the help. I may be back for more. I hope not, but the way my luck goes... Well, as suspected, it crapped out again. I get this at the end of the fedup command: Traceback (most recent call last): File /bin/fedup, line 239, in module main(args) File /bin/fedup, line 219, in main for line in s.format_details(): AttributeError: 'ProblemSummary' object has no attribute 'format_details' Prior to that, I get a ridiculous amount of package conflict errors, most invoving perl: perl-Params-Classify-0.013-7.fc19.x86_64 requires perl-4:5.16.3-266.fc19.x86_64 So, I guess I'm in deep trouble here. I suspect this is going to require a full install of F20 rather than a fedup. Dang! -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- -Hello. My PID is Inigo Montoya. You `kill -9'-ed my parent- - process. Prepare to vi. - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup failure from F19-F20
On 04/28/2014 03:49 PM, Adam Williamson issued this missive: On Mon, 2014-04-28 at 15:42 -0700, Rick Stevens wrote: Thanks again for the help. I may be back for more. I hope not, but the way my luck goes... Well, as suspected, it crapped out again. I get this at the end of the fedup command: Traceback (most recent call last): File /bin/fedup, line 239, in module main(args) File /bin/fedup, line 219, in main for line in s.format_details(): AttributeError: 'ProblemSummary' object has no attribute 'format_details' That looks like some issue with printing a nice summary of what went wrong, but not actually anything to do with what went wrong. Prior to that, I get a ridiculous amount of package conflict errors, most invoving perl: perl-Params-Classify-0.013-7.fc19.x86_64 requires perl-4:5.16.3-266.fc19.x86_64 So, I guess I'm in deep trouble here. I suspect this is going to require a full install of F20 rather than a fedup. Dang! Don't give up yet. This is the 'real problem', and just because there seem to be a lot of errors doesn't mean it's intractable, as they all seem to be related. If you could pastebin the entire output, I might be able to help. I appreciate it, Adam. Unfortunately the log is 28K lines (3.2MB). I don't think pastebin would appreciate me trying to stuff all of that rot in there. I zipped it and it's now only 335KB, but still pretty big to try to stuff into a free site. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - Politicians are the opposite of pickpockets because you never see - -them take their hand out of your pocket.- - -- Larry Fine - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup failure from F19-F20
On 04/28/2014 04:15 PM, Samuel Sieb issued this missive: On 04/28/2014 03:42 PM, Rick Stevens wrote: Prior to that, I get a ridiculous amount of package conflict errors, most invoving perl: perl-Params-Classify-0.013-7.fc19.x86_64 requires perl-4:5.16.3-266.fc19.x86_64 That looks more like part of a broken dependency chain. For example maybe you installed a package that requires some specific version of a perl package, but doesn't have an update. Looking at the litany of errors reported in fedup.log, virtually every Perl module I have seems to whine and they all say they want that perl-4:5.16.3-266.fc19.x86_64 RPM. That is the perl version installed and it's the latest version of perl available for F19. I'm rather stumped. I will say that at one point the system did spit out a Reboot to complete upgrade message and the system sorta sat there for a minute. I thought Hot dang! Just let it finish up..., but then the module errors started scrolling by and I lost the message off the top of the rollback buffer. I don't see a record of that message in the fedup.log file either, so I think it was just teasing me. I may rename this machine from prophead to Lucy, since she keeps pulling the football away just as I'm going to kick it. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - OK, so you're a Ph.D. Just don't TOUCH anything! - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
fedup failure from F19-F20
Hi, gang. I ran into a nasty trying to upgrade one of my machines from F19 to F20. Two other machines upgraded without issues, but this one is rather nasty. I did an initial fedup --network 20 on the F19 box and ran into the famous google-chrome repo issue, so I reran it with a --disablerepo=google-chrome. That went fairly well until the upgrade check determined that I needed another measly 10M in /boot. So I went in and cleaned up some old kernels, initrds and such in /boot and freed up 55M of space in there. I reran the fedup --network --disablerepo=google-chrome 20 and everything went pretty well until the very end. Now I'm getting this: updates/20/x86_64/group | 1.6 MB 00:00 finding updates 75% [=== ] Downloading failed: failure: repodata/bc8c39a750b2ea65acf35ae2a16474dfa17e0f8952f8744cd523b16a06cfcb48-filelists.sqlite.bz2 from _local: [Errno 256] No more mirrors to try. file:/var/lib/yum/plugins/local/repodata/bc8c39a750b2ea65acf35ae2a16474dfa17e0f8952f8744cd523b16a06cfcb48-filelists.sqlite.bz2: [Errno 14] curl#37 - Couldn't open file /var/lib/yum/plugins/local/repodata/bc8c39a750b2ea65acf35ae2a16474dfa17e0f8952f8744cd523b16a06cfcb48-filelists.sqlite.bz2 No, that file does NOT exist in /var/lib/yum/plugins/local/repodata. There are others in there, but not that specific one. Rerunning the command keeps coming up with that same error. fedup --clean doesn't help (get the same error). I'm afraid this machine is now in a very sick state and I'm petrified that, should I lose power or something else happens that will cause it to reboot, it's going to be dead. I have backups of the machine, but jeeze! Any ideas on what to do? I'm posting this to the test list because this seems to be more of a potential issue for future upgrades. If I should post this to the other lists, please let me know. Thanks for any assistance you can offer! -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - What's small, yellow and very, VERY dangerous? The root canary! - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup failure from F19-F20
On 04/25/2014 10:25 AM, Samuel Sieb issued this missive: On 04/25/2014 10:12 AM, Rick Stevens wrote: I'm afraid this machine is now in a very sick state and I'm petrified that, should I lose power or something else happens that will cause it to reboot, it's going to be dead. If all you've done is run fedup, then nothing has happened to the installed Fedora. You're fine. Try doing a yum clean and deleting the the /var/tmp/system-upgrade directory. Then try fedup again. If fedup actually completed at some point, then be careful when rebooting. There may be an upgrade entry in the boot list. But since it sounds like fedup never actually successfully completed, there shouldn't be one. Samuel, thank you for your help. I did a yum clean which completed with no errors. There is no /var/tmp/system-upgrade directory that I can find (a lot of old systemd stuff though, so I purged that). There are a lot of both F19 and F20 RPMs in /var/lib/yum/plugins/local, however. Should these be purged as well? I don't know of a way to see what's in the grub2 boot menu other than actually trying a reboot, but I'll try to be careful. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - If at first you don't succeed, quit. No sense being a damned fool! - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup failure from F19-F20
On 04/25/2014 10:59 AM, Samuel Sieb issued this missive: On 04/25/2014 10:44 AM, Rick Stevens wrote: I did a yum clean which completed with no errors. There is no /var/tmp/system-upgrade directory that I can find (a lot of old systemd stuff though, so I purged that). /var/tmp/fedora-upgrade maybe? Are you sure you have the latest fedup? Maybe related to the next question. As far as I know, yes, it's the latest fedup for F19: fedup.noarch0.8.0-4.fc19 fedup-dracut.x86_64 0.7.3-1.fc19 fedup-dracut-plymouth.noarch0.7.3-1.fc19 There are a lot of both F19 and F20 RPMs in /var/lib/yum/plugins/local, however. Should these be purged as well? Sounds like you have yum-plugin-local installed. I would recommend removing that first. And all those RPMs. Yup, I have yum-plugin-local installed. I'll kill it off and remove the /var/lib/yum/plugins/local RPMs. Now, assuming I clean all that cruft up (getting rid of the plugin-local stuff, getting rid of the RPMs), how do I proceed with the upgrade? It seems like fedup is stuck looking for that sqllite file which doesn't exist. Is there a cache somewhere I need to purge? -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - Celibacy is not hereditary. - - -- Guy Goden - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup failure from F19-F20
On 04/25/2014 02:54 PM, Adam Williamson issued this missive: On Fri, 2014-04-25 at 11:49 -0700, Samuel Sieb wrote: On 04/25/2014 11:42 AM, Rick Stevens wrote: Yup, I have yum-plugin-local installed. I'll kill it off and remove the /var/lib/yum/plugins/local RPMs. Now, assuming I clean all that cruft up (getting rid of the plugin-local stuff, getting rid of the RPMs), how do I proceed with the upgrade? It seems like fedup is stuck looking for that sqllite file which doesn't exist. Is there a cache somewhere I need to purge? If you followed the previous steps I mentioned, all the caches should be cleaned, but I strongly suspect your problem was caused by that plugin. So just try fedup again. ^^^ this, but if it turns out you do need to clean up after the earlier failed fedup run for some reason, try 'fedup --clean'. I did that along with a yum clean all just for good measure. I got pulled off onto other things today, but I'm doing a fedup --disablerepo=google-chrome --network 20 right now. We'll see how it goes. Thanks again for the help. I may be back for more. I hope not, but the way my luck goes... -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - Memory is the second thing to go, but I can't remember the first! - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: A different way of installing Fedora
On 09/26/2013 09:51 AM, Eric Blake issued this missive: On 09/26/2013 10:43 AM, John Morris wrote: 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 virt-sysprep is a great tool for doing all of the neutering necessary when cloning images. It was originally designed for VM image clones, but works just as well on bare metal disk images for your use case. Uh, silly of me, but isn't this what things like puppet and its kin are for? We do a lot of deployments using puppet. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- -He who laughs last thinks slowest. - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome settings unexpected values
On 09/25/2013 09:11 AM, Chris Murphy issued this missive: On Sep 25, 2013, at 12:00 AM, Igor Gnatenko i.gnatenko.br...@gmail.com wrote: On Tue, 2013-09-24 at 23:11 -0600, Chris Murphy wrote: https://dl.dropboxusercontent.com/u/3253801/IMG_20130924_185026.jpg SettingsSystem: Details a. Device name is showing hostnamectl transient name, not static name. I just tried this in F19 and it shows the static name. So this seems backwards now with Gnome 3.9. How to reproduce ? Baremetal: hostnamectl set-hostname f20s.localdomain --static hostnamectl set-hostname oldmac.localdomain --transient On every boot, Gnome says the Device name is oldmac.localdomain. On a VM of F19, Gnome uses f19s.localdomain rather than vbox.localdomain. Actually I probably ought to ask which of these even ought to be set. I find the idea of static, pretty and transient hostnames thoroughly confusing. I'm not setting a pretty hostname, btw. The commands should be: hostnamectl --static set-hostname f20s.localdomain hostnamectl --transient set-hostname oldmac.localdomain Not sure what happens if you place the options after the commands. The default is to set ALL hostnames to that specified so if the command is ignoring the option (because it's at the end), the last hostnamectl command you specified (in this case, oldmac.localdomain) becomes the pretty, transient AND static name. More or less what you're seeing. You should also check /etc/hosts to see if there's an entry in there for 127.0.0.1 referring to oldmac.localdomain. Also keep in mind that a number of the utilities do reverse DNS lookups instead of using the hostname bits so you may be seeing a DNS artifact here. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - Do you suffer from long-term memory loss? I don't remember - --- Chumbawumba, Amnesia (TubThumping) - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Has anybody else seen a delay in xfce?
On 10/08/2012 05:15 AM, Kevin Martin issued this missive: snip -- Regards, Kevin Martin -- I use F17 and Xfce. My PC is very old (Athlon) so I see a delay when switching to a thunderbird window but it's sometimes less than a second, sometimes maybe a couple of seconds. So specially if your computer isn't as old then maybe you have a video driver issue? Just a guess that might be wrong. So the issue exists but for some reason you're having it exaggerated. -- test mailing list test@lists.fedoraproject.org mailto:test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test I don't see any issues on my F18 instances (VirtualBox) and F18 installed on my laptop, so it must be something there is depending on hardware. Tim Hmm, the switching problem is solved. But a second problem (which I hoped would be fixed if I got the switching problem figured out) still exists. For a little more background, in order to get the nouveau driver to work with my card I had to set Option NoAccel 1 in the Devices section of my xorg.conf filewithout this X would crash every time (there is an open bugzilla about this that nobody seems interested in working on). Are you certain you don't have something else in the /etc/X11/xorg.conf.d directory that's turning it back on? I used to start the OS with nouveau.noaccel=1 in the linux line but that has stopped working (yet another bugzilla that nobody is working on that I can tell). And I solved my switching problem by adding this to my xorg.conf: Section Extensions Option Composite off EndSection So I can switch from workspace to workspace with no issue now. The other issue I'm still seeing is when I move a window within the workspace...instead of the window just moving to the new location that I drag it to there is a noticeable delay in the repaint of the windowif I set it so that the content of the window is not shown during the move it's less noticeable but still obvious. And occasionally the system doesn't recognize when I release the mouse button during the move such that if I release the button but continue to move the mouse the window still follows the mouse and ends up in a place that I didn't intend. So I'm getting closer and will continue to experiment. Any thoughts or suggestions greatly appreciated. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - Microsoft is a cross between The Borg and the Ferengi. - - Unfortunately they use Borg to do their marketing and Ferengi to - - do their programming. -- Simon Slavin - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: is the name ok (my reply a bit long)
On 04/06/2012 11:36 AM, Frank Murphy wrote: On 06/04/12 18:24, george2 wrote: of the release name will not offend women, parents, and many who are spiritual or profess a religion? No mater how liberal a guy I might be, this expresses a concern for how open source might be perceived by the general public. Even if these pictures and words were done in fun, isn't the association now caustic. The only way to do that is not to have a name. Because there will always be someone to get offended. At times some common sense has to be used. Putting in my two cents (pence, 5% of a euro, whatever), there is absolutely no way to prevent someone from being offended because people are so willing (in fact fervently wish) to _be_ offended. Even the name Fedora can cause grief. In northern Africa I can see someone whining We've been slighted! Why didn't they name it 'Kepi'? Or in the middle east, burnoose. You get the drift. Chevrolet Motors had such an issue in the 60's with the Nova. They meant bright star, but the joke in Mexico and such was won't go (no va). I agree, common sense should be the guiding factor, but common sense is rapidly becoming such a rare commodity now I doubt you can find it in some places. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - Death is nature's way of dropping carrier - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: is the name ok (my reply a bit long)
On 04/06/2012 11:54 AM, Rick Stevens wrote: On 04/06/2012 11:36 AM, Frank Murphy wrote: On 06/04/12 18:24, george2 wrote: of the release name will not offend women, parents, and many who are spiritual or profess a religion? No mater how liberal a guy I might be, this expresses a concern for how open source might be perceived by the general public. Even if these pictures and words were done in fun, isn't the association now caustic. The only way to do that is not to have a name. Because there will always be someone to get offended. At times some common sense has to be used. Putting in my two cents (pence, 5% of a euro, whatever), 2% of a euro, sorry! Bad day on the keyboard. :-p -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - Diplomacy: The art of saying Nice doggy! until you can find a - -big enough rock.- -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Anaconda should be rewritten in a compiled language!
On 02/17/2012 02:27 PM, FRank Murphy wrote: On 17/02/12 20:52, John Dulaney wrote: I say, write it in Fortran! Cobol. I'd vote for PL/1, APL, Ada, or BCPL. But let's get really odd... how about Lisp? After all, we want Anaconda to self-extend to handle all possible conditions, don't we? Neural networking sounds about right to fill the bill. scurrying back to my hole with tongue planted firmly in cheek -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- -Hard work has a future payoff. Laziness pays off now. - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Anaconda .25 and 3TB Drive Oops
On 11/03/2011 11:59 PM, Chuck Forsberg WA7KGX N2469R wrote: Still picking up the pieces... After moving some large file systems off the first 3TB drive I zeroed the partition table and started with a BIOS partition. After setting up the various partitions the installer insisted on putting the boot on the one 2TB drive I have in the system. I then disconnected the 2TB drive and rebooted the installer. Without a smaller drive to put the boot loader on, the installer refused to move off the partition defining page. I had to reconnect the 2TB drive to install Verne. So, apparently, Verne cannot install on a machine with only 3TB drives. Did you create a partition that was smaller than 2TB in the partition- definition page? IIRC, a lot of the low level stuff has a 32-bit limit on the block number they need to access and on most drives, 2^31 is 2TB. I suspect the installer is aware of this and is enforcing that limit. If you don't have a partition that's 2TB there's no place for the installer to put the boot images on that it can guarantee the BIOS and stage1 boot loader can see, so it's not letting you go on. Sorry if this has been addressed earlier in the thread. I tuned in late. -- - Rick Stevens, Systems Engineer, C2 Hosting ri...@nerd.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - Always remember you're unique, just like everyone else. - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: USB Flash Drive fs chk...
On 10/04/2011 12:33 AM, Rob Healey wrote: Greetings: Is there a way to do a filesystem check on my USB Flash Drive from within my FC16 x86_64 system? Just like any other device, but it shouldn't be necessary. If you must, do a mount and figure out which device it is, then unmount it and fsck device-name where device-name is the device containing the filesystem. -- - Rick Stevens, Systems Engineer, C2 Hosting ri...@nerd.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - I was married by a judge. I should have asked for a jury. - - -- Groucho Marx - -- -- 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 04/20/2011 06:39 PM, John Watzke wrote: [snip] 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. 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. 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 -- Rick Stevens -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Rawhide web server error
On 12/16/2010 02:25 PM, Rob Healey wrote: Greetings: I am trying to figure out why I can NOT get my web server to run!?! I have a completely updated rawhide installation, and this is what i am getting from my error_log file... [Thu Dec 16 14:18:22 2010] [notice] Digest: generating secret for digest authentication ... [Thu Dec 16 14:18:22 2010] [notice] Digest: done [Thu Dec 16 14:18:22 2010] [error] (2)No such file or directory: could not create /etc/httpd/run/httpd.pid /etc/httpd/run is usually a symlink to ../../var/run/httpd (which should ultimately be /var/run/httpd). Do an ls -l on /etc/httpd/run and make sure it's not a broken link. In other words, make sure that /var/run/httpd exists, is owned by root:apache and has 710 (rwx--x---) permissions. -- - Rick Stevens, Systems Engineer, C2 Hosting ri...@nerd.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - Daddy, why doesn't this magnet pick up this floppy disk? - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Anybody has problems too with totem in F14?
On 09/30/2010 04:12 AM, Patrick Lists wrote: On 09/30/2010 10:01 AM, Joachim Backes wrote: Having applied all F14 updates. Anybody sees this too? Starting totem: totem totem: symbol lookup error: totem: undefined symbol: g_application_get_type Yes I have seen this too. Downgrading glib2 solves it. I have not seen an update yet for glib2 that fixes this. With the mess the recent glibc caused and now glib2 I wonder what is so special about packages starting with glib :) Perhaps they're too glib. Running your mouth off often results in the curious condition called foot-in-mouth-disease. :-) -- - Rick Stevens, Systems Engineer, C2 Hosting ri...@nerd.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - Real Time, adj.: Here and now, as opposed to fake time, which only - -occurs there and then - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
dkms package not available for F13
Are there plans afoot to release a dkms package for F13? I ask because there seems to be none available for F13 although the database shows it as being approved. Should I simply force-install the F12 version in the interim? -- - Rick Stevens, Systems Engineer, C2 Hosting ri...@nerd.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - The Theory of Rapitivity: E=MC Hammer- - -- Glenn Marcus (via TopFive.com) - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: f-e-k improvement discussion continued
On 07/19/2010 07:35 AM, Adam Williamson wrote: On Fri, 2010-07-16 at 23:01 -0400, Bob Lightfoot wrote: BobLfoot's next comment: I just ran yum update --enable-repo=updates-testing --skip-broken -y and when I went to run f-e-k I was presented with three packages to provide feedback on. 1) ppp 2) xorg-x11-xinit 3) xsane-common and xsane-gimp. 1) I've never used ppp networking so this would be a package I'd of karma 0 and not tested comment prior to Adam's request that we not do so. The Actually, ppp is a critical path package, so going by what I wrote, it would be okay to leave a 0 karma 'didn't break critical path but not directly tested'. (Although actually, for ppp, we really need feedback from people who actually use PPP connections). suggestion to just remove the package is unacceptable in this case also since yum erase ppp wipes out Network Manager. So not testing would be a nice choice here for me rather than having to skip it every time. a karma of I or 7 which didn't factor into the total karma math but caused the system not to represent works great. 2) I run x on my VM but don't know if I have an Xorg file or not and wouldn't have a clue how to test for a missing bang to shebang unless the developer choose to publish a test protocol. Again, a critical path package, so it's fine to leave a comment here. And yeah, that's a terrible update description, just awful. (Sorry, mcepl :) A shebang is one of those bits at the start of a script that looks like this: #!/bin/bash which tells the system what shell the script is supposed to be run with. The shebang is the #! part. The # is the 'she', the ! is the 'bang'. I believe it's shabang, with the # being the musical notation for sharp. Some other names for it are hash and Americans sometime call it a pound sign (yes, I'm an American). The ! being called bang is sort of self-evident to anyone who's read any comics or watched the campy 1960s Batman series. Does anyone remember bang-path mail routing? :-) -- - Rick Stevens, Systems Engineer, C2 Hosting ri...@nerd.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - To iterate is human, to recurse, divine. - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: f-e-k improvement discussion continued
On 07/19/2010 10:17 AM, Adam Williamson wrote: On Mon, 2010-07-19 at 13:03 -0400, Al Dunsmuir wrote: The # is an invented character that originated at ATT for touch tone dialing. The official name is octothorpe - Greek for 8 points... but no one ever calls it that. No, it existed long before touch tone phones. I know =) I think it got called pound sign because it was placed on keyboards where typewriters used to place the British Pound Sterling symbol. Older publications and invoices actually did use the # as pound in the States (for weight measurements, not currency). It's also often used for count on tally sheets. I've seen it on typewriters made back in the 1920s, LONG before ATT existed. They used it because it was familiar to many people in the States. They certainly didn't invent it. See my post - it's only called 'pound sign' in the States. British people never call it that. Don't know what it's called in other countries. Jeeze, looks like I started something evil here! But I DO so love to roil the normally placid waters of certain lists (he says with a sinister cackle!) -- - Rick Stevens, Systems Engineer, C2 Hosting ri...@nerd.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - UNIX is actually quite user friendly. The problem is that it's - - just very picky of who its friends are! - -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proven tester wiki love
On 07/07/2010 12:29 PM, mike cloaked wrote: On Wed, Jul 7, 2010 at 8:16 PM, Adam Williamsonawill...@redhat.com wrote: Thinking about it, though, we could consider a slightly different process for the kernel, as it's a component that's *extremely* subject to different experiences for different users. I'm not sure the workflow we've designed will work terribly well for kernels. I suspect it'll be all too easy for a kernel which actually contains a major regression to be approved; all it needs is for a proventester who doesn't happen to own the hardware concerned to find it works fine on their system, and file a +1, and anyone else to file a +1 too, and it'd be approved, even though someone who does own the hardware might come by and test an hour later and find the problem... we might want to design a system for the kernel where all proventesters hold off posting positive feedback for a day or two, until several proventesters and regular testers have had the chance to check for regressions. That was exactly my thought too - I saw these kernel updates were there but thought that to satisfy the current criteria as best I could I would wait and see what comments that came in to bodhi over the next day or so looked like and then install and test. If I then saw no negatives, and my own tests found no problems then I felt +1 would be valid, but I wanted re-assurance from people here first. It would seem that in this situation neutral karma from a proventester would not be particularly useful as the package would not get the necessary push to stable unless a proventester gives +1. If this is acceptable as a way forward I would be happy with that but as you say for the kernel perhaps an additional paragraph in the draft would be useful. Silly idea...how about assigning a requirement that each bugfix (or at least a majority of them) in a kernel require positive karma before the kernel is blessed? The idea is that most bugfixes are just that--fixes. Otherwise it'd be silly to release it, not so? It's just a thought. It's the criteria I use when I release code. -- - Rick Stevens, Systems Engineer, C2 Hosting ri...@nerd.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - You possess a mind not merely twisted, but actually sprained.- -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
